On Aug 15, 2006, at 12:14 AM, Guido van Rossum wrote: > > Feel free to submit a patch for Python 2.6.
Please see http://sourceforge.net/tracker/index.php? func=detail&aid=1540617&group_id=5470&atid=305470 > Perhaps it is in POSIX? Yes, "ssize_t - Used for a count of bytes or an error indication.", defined in sys/types.h . I promised to shut up, but let me respond to Martin: On Aug 15, 2006, at 3:25 AM, Martin v. Löwis wrote: > Alexander Belopolsky wrote: >> [snip] 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. Google tells me I am not the only one: <http://dbforums.com/ showthread.php?t=1430615>. What happened to "readability counts"? > > In the rationale (XRAT) they say > > "This is intended to be a signed analog of size_t." That's POSIX rationale <http://www.opengroup.org/onlinepubs/009695399/ xrat/xsh_chap02.html>. PEP 353 says: "A new type Py_ssize_t is introduced, which has the same size as the compiler's size_t type, but is signed." > > They don't mandate it to have the same size, but it is the expectation > that implementations typically will. That's one of the reasons why POSIX' ssize_t is a wrong analogy. Another reason is that POSIX interprets negative values of ssize_t as "an error indication", not as an offset from the end. A better POSIX analogy would be off_t (as used in lseek). > > In the discussion, ptrdiff_t was never brought up as an alternative Yes, it was, by you <http://mail.python.org/pipermail/python-dev/2006- January/059562.html> :-). I was not suggesting Py_ptrdiff_t. My suggestion was "Py_index_t", but I am six month late :-(. _______________________________________________ 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
