> Guido van Rossum wrote: > > I'm all for this. I imagine there are many subtleties though -- I > > know I consciously chose 'int' for this purpose in Python 0, and the > > assumption that it fits in an int is everywhere. I would trust a > > decent compiler to find most cases, but not all. [MvL] > The MS Win64 compiler (Itanium) is pretty good at finding size_t/int > conversions, as size_t is wider even than long on the system. I have > patches sitting on my disk to change all function signatures, but > not the structure layouts. They are (unfortunately) still incomplete, > and it is doubtful whether I can complete them before PyCon. Maybe it can be a sprint topic? > > Also, occasionally (size_t)(-1) may be used to indicate an error > > (e.g. PySequence_Size()). > > This is the tricky part that I want to defer in the first round > of patches: I believe ob_size should be a signed type, so it should > be ssize_t where available. The tricky part is finding an appropriate > type on systems where ssize_t is not available. Why not simply use Py_intptr_t then? > (size_t)(-1) is not a problem per se; this is well-defined on all > ISO C compilers. However, some code may expect that the error marker > is smaller than any other value, which would not be the case for > (size_t)(-1). Right, that's what I meant. --Guido van Rossum (home page: http://www.python.org/~guido/)
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