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

Brett Cannon brett at python.org
Sun Apr 2 03:26:38 CEST 2006

On 4/1/06, Tim Peters <tim.peters at gmail.com> wrote:

[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 PYFORMATSIZET (since there's almost nothing portably useful you can say about standard C's billion names for "some kind of integer"). In effect, the PYFORMATSIZET 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(Pyssizet) <=_ _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 PYFORMATSIZET "z" in the generated pyconfig.h. Note that if pyconfig.h defines PYFORMATSIZET, pyport.h believes whatever that says. It's the purpose of "z" to format sizet-ish arguments, so gcc complaints should end then.

I vote we move to C99. =) If that doesn't happen, I guess the above solution is the best. I am probably not the best person to tweak the Makefile for this, but I can if no one gets to it.

-Brett

More information about the Python-Dev mailing list