[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