RE: source(builtin) and read(2)

[Schwarz, Konrad]

> -----Original Message-----
> From: Paul Eggert [mailto:address@hidden 
> "Schwarz, Konrad" <address@hidden> 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.
> 

Sorry, you seem to have missed my point: even in the "old days", i.e.,
in cases where sizeof (ptrdiff_t) > sizeof (size_t), it makes sense to
define the return value of read() to have type ptrdiff_t, since this
ensures that all objects (that sizeof is valid for) can be read in a
single operation.  Otherwise, technically, a check that the size of the
object is less than SSIZE_MAX bytes is required.  What is the
justification for making the return value of read() have type ssize_t?

Regards,

Konrad