[Python-Dev] PY_FORMAT_SIZE_T warnings on OS X

[Tim Peters]

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