> -----Original Message----- > From: Clive D.W. Feather [mailto:[EMAIL PROTECTED] > > While we're at it, I would be interested in the rational > for "inventing" > > ssize_t and not using ptrdiff_t instead, if anyone would care to > > comment. > > size_t has to be able to hold the size of the largest object. > It is an unsigned type. > > ptrdiff_t has to be able to hold the largest difference > between two pointers; it is a signed type. > > The two need not be a signed/unsigned pair. For example, if a > system has a maximum object size of 64,000 bytes, then size_t > needs to be at least 16 bits but ptrdiff_t needs to be at > least 17 bits. Thus it would be legitimate for size_t to be > (16 bit) unsigned short but ptrdiff_t to be > (32 bit) signed int. > > ssize_t is the signed type corresponding to size_t. In the > above example, it is required to be signed short. It's > possible for a legitimate subtraction of two pointers to > generate a value that can't fit in ssize_t. > However, because size_t and ssize_t are a signed/unsigned > pair, they have useful properties (for example, when dealing > with varargs lists).
Ok. I see that e.g., http://www.opengroup.org/onlinepubs/009695399/functions/read.html makes clear that "If the value of nbyte is greater than {SSIZE_MAX}, the result is implementation-defined.", so these types of functions can't deal with arbitrary objects (in the case that sizeof (ssize_t) < sizeof (ptrdiff_t)) anyhow. If ptrdiff_t had been used as the return type for these functions, this restriction could have been lifted, since per definition, a ptrdiff_t can represent the size of all objects. This would seem to have greater utility than the ability to interchange ssize_t and size_t when dealing with varargs lists. >From C89/C99 I see that "size_t [...] is the unsigned integer type of the result of the sizeof operator" but not that objects up to 1 << sizeof (size_t) * CHAR_BIT need to be supported by the implementation (e.g., in the above example, the implementation could defined the maximum object size as 1 << 15 bytes, and then ptrdiff_t and size_t could be a signed/unsigned pair). In fact, this is the situation in all ABIs I have ever looked at. Technically, having sizeof (ptrdiff_t) != sizeof (size_t) seems wrong for a wide class of CPU architectures, because both at some point should reflect the width of the registers used for addressing. Was there ever any pressure from implementers for introducing ssize_t in lieu of ptrdiff_t? Regards, Konrad
