[Python-Dev] PY_FORMAT_SIZE_T warnings on OS X

Brett Cannon brett at python.org
Sun Apr 2 02:40:56 CEST 2006


On 4/1/06, Tim Peters <tim.peters at gmail.com> wrote:
> [Brett Cannon]
> > I think these are all Tim's fault =) :
>
> No, they're Anthony's fault :-)  He added this clause to pyport.h yesterday:
>
> #   if SIZEOF_SIZE_T == SIZEOF_INT
> #       define PY_FORMAT_SIZE_T ""
>
> and that's obviously triggering on your platform.  He added this (at
> my suggestion) to shut up similar gcc warnings on some other box.
> Before he added it, PY_FORMAT_SIZE_T was "l" on that box (and on
> yours)  If it had remained "l", you wouldn't be getting warnings now,
> but he still would.
>

Great, so either Anthony gets warnings or I do.

> On his box, the gripes where about passing a size_t argument to a
> "%lu" format, but size_t resolved to unsigned int, not to unsigned
> long.  sizeof(int) == sizeof(long) on that box (and on yours), so the
> warning isn't really helpful.
>

Well that figures.

> > Objects/object.c: In function '_Py_NegativeRefcount':
> > Objects/object.c:144: warning: format '%d' expects type 'int', but
> > argument 7 has type 'Py_ssize_t'
>
> And I bet (you should check) that Py_ssize_t resolves to "long" on
> your box, and that sizeof(long) == sizeof(int) on your box, so that
> again the warning is just a damned nuisance.
>
> > ... [similar complaints] ...
>
> > What's odd about them is that that the use of PY_FORMAT_SIZE_T seems
> > to be correct, so I don't know what the problem is.
>
> My best guess is above.  gcc appears to be generating type complaints
> based on "name equivalence" rather than "structure equivalence" here
> (meaning it's comparing integer types by the names they resolve to
> rather than to the combination of size and signedness regardless of
> name).  Worming around that would probably require a bunch of
> poke-and-hope experimenting with various gcc's, of which I have none
> :-)

This is just so ridiculous.  Is there even a way to do this
reasonably?  Would we have to detect when Py_ssize_t resolves to
either int or long and when the size of both is the same force to the
same name on all platforms?

>
> >  Unfortunately ``gcc -E Include/pyport.h`` is no help since PY_FORMAT_SIZE_T
> > is not showing up defined (possibly because gcc says it can't find pyconfig.h).
>
> You can run on it this part in isolation:
>
> #ifndef PY_FORMAT_SIZE_T
> #   if SIZEOF_SIZE_T == SIZEOF_INT
> #       define PY_FORMAT_SIZE_T ""
> #   elif SIZEOF_SIZE_T == SIZEOF_LONG
> #       define PY_FORMAT_SIZE_T "l"
> #   elif defined(MS_WINDOWS)
> #       define PY_FORMAT_SIZE_T "I"
> #   else
> #       error "This platform's pyconfig.h needs to define PY_FORMAT_SIZE_T"
> #   endif
> #endif
>
> after sticking on the right expansions for the SIZEOF_xyz thingies --
> but it's clear enough from the error messages that the SIZEOF_INT
> branch is triggering (it's complaining about format '%d', not format
> '%ld' or format '%Id').
>

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?  =)

-Brett


More information about the Python-Dev mailing list