On 4/1/06, Tim Peters <[EMAIL PROTECTED]> 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 _______________________________________________ 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