"Schwarz, Konrad" <[EMAIL PROTECTED]> writes: > The argument that since ptrdiff_t is intended to represent the > difference of pointers makes it somehow unsuitable to represent the > result of read()/write() is missing the point: on any useful ABI, > ptrdiff_t can represent the size of any object, can represent 0, and can > represent -1, which is what read() and cousins require.
That's true nowadays, but in the old days there may have been a point to distinguishing between ptrdiff_t and ssize_t. I wasn't there, but I imagine that the original point of ptrdiff_t was that it could be wider than size_t. Consider the case of a machine with 16-bit addresses, 32-bit registers, and where objects can be larger than 2**15 bytes. (The Motorola 68000 in 16-bit address mode comes to mind.) In such a machine size_t (and therefore ssize_t) is 16 bits, and but it's useful to make ptrdiff_t 32 bits. These days the distinction isn't all that relevant, because it's not so useful to have objects that are between 2**31 and 2**32 bytes in size. So it would make sense now to require that ssize_t and ptrdiff_t must be the same width. I don't know of any modern counterexamples.
