On 4/1/06, Tim Peters <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
