[Python-Dev] PY_FORMAT_SIZE_T warnings on OS X (original) (raw)

Tim Peters tim.peters at gmail.com
Sun Apr 2 03:22:24 CEST 2006

[Brett Cannon]

... This is just so ridiculous.

Ya think ;-)?

Is there even a way to do this reasonably?

Not really in C89. That's why C99 introduced the "z" printf modifier, and approximately a billion ;-) format macros like PY_FORMAT_SIZE_T (since there's almost nothing portably useful you can say about standard C's billion names for "some kind of integer"). In effect, the PY_FORMAT_SIZE_T case was important enough that C99 moved it directly into the printf format syntax.

Would we have to detect when Pyssizet resolves to either int or long

It's worse that that: there's no guarantee that sizeof(Py_ssize_t) <= sizeof(long), and it fact it's not on Win64. But Windows is already taken care of here.

OK, so how should we solve this one? Or should we just ignore it and hope gcc eventually wises up and starting using structural equivalence for its printf checks? =)

For gcc we could solve it in the obvious way, which I guess Martin was hoping to avoid: change Unixish config to detect whether the platform C supports the "z" format modifier (I believe gcc does), and if so arrange to stick

#define PY_FORMAT_SIZE_T "z"

in the generated pyconfig.h. Note that if pyconfig.h defines PY_FORMAT_SIZE_T, pyport.h believes whatever that says. It's the purpose of "z" to format size_t-ish arguments, so gcc complaints should end then.

More information about the Python-Dev mailing list