This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients godlygeek, pablogsal, serhiy.storchaka, vstinner
Date 2021-09-30.09:04:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1632992660.93.0.77973645157.issue45325@roundup.psfhosted.org>
In-reply-to
Content
> I think that the risk for other formatting parameters is smaller, because you know, that there are different formatting parameters for different integer and floating point types, and for pointers, and you know that you should care about truncation and overflow if the type of the argument is different from the type of the parameter.

IMO such problem can be solved with documentation.

Pablo: can you try to explain the problem in the documentation, and maybe provide an example in the doc showing how to avoid it?

I guess that a generic fix is to replace "value" with "value != 0". In C, "expr != 0" is an int, no?

What I understood is that Py_BuildValue("p", value) is problematic if value type is not int.

"!value" or "!!value" also has the issue if I understood correctly. Like:

    long value = 3; Py_BuildValue("p", !value);

I agree with Serhiy that Py_BuildValue() is ok-ish with other formats, but IMO it's the responsibility of the developer to pass the expect type (int for "p" format).

This problem is not specific to Py_BuildValue(). printf() also has exactly the same issue. Such code has an undefined behavior:

  long long x = 1; print("%d\n", x);

You must cast explicitly:

  long long x = 1; print("%d\n", (int)x);

Or use a different format, like:

  long long x = 1; print("%lld\n", x);
History
Date User Action Args
2021-09-30 09:04:20vstinnersetrecipients: + vstinner, serhiy.storchaka, pablogsal, godlygeek
2021-09-30 09:04:20vstinnersetmessageid: <1632992660.93.0.77973645157.issue45325@roundup.psfhosted.org>
2021-09-30 09:04:20vstinnerlinkissue45325 messages
2021-09-30 09:04:20vstinnercreate