RE: source(builtin) and read(2)

[Schwarz, Konrad]

> -----Original Message-----
> From: Clive D.W. Feather [mailto:address@hidden 
> > 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