[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4