[Python-Dev] PY_FORMAT_SIZE_T warnings on OS X

[Brett Cannon]

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 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 Py_ssize_t 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.
>

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