Alexander Belopolsky wrote: > Since on most platforms ssize_t is the same as long, the choice > between the two is just a matter of self-documenting code.
No, it would be an actual change: on Win64, sizeof(Py_ssize_t)>sizeof(long). > Speaking > of which, I find it unfortunate that the name Py_ssize_t was selected > for the typedef. I would prefer Py_index_t. The first time I saw > Py_ssize_t, I did not notice the double 's' and thought it was an > unsigned type. Hmm. That you fail to read it correctly can hardly be an argument against it. > On the second look, I've realized that it is signed > and started wondering why not ptrdiff_t. I understand that ssize_t > is defined by POSIX as the return type of functions such as "read" > that can return either size or -1 for error. I don't think POSIX > mandates sizeof(size_t) == sizeof(ssize_t), but I may be wrong. In the rationale (XRAT) they say "This is intended to be a signed analog of size_t." They don't mandate it to have the same size, but it is the expectation that implementations typically will. > I would agree that ptrdiff_t, although standard C, is not a very > intuitive name, but ssize_t is even less clear. In the discussion, ptrdiff_t was never brought up as an alternative (intptr_t was; see the PEP for why it is unsuitable). ssize_t seemed most natural to me since size_t is the C "number of bytes" type, and we need a signed version of it. Regards, Martin _______________________________________________ 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
