Re: source(builtin) and read(2)

[Paul Eggert]

Geoff Clare <address@hidden> writes:

> Paul Eggert <address@hidden> wrote, on 30 Mar 2007:
>>
> Picky, picky.  Let me restate it as "if the code ... outputs
> "SSIZE_MAX wrong" (through normal execution, not undefined behaviour),

Fine, but the point is that there's no portable way for an application
to determine whether adding 1 to a ssize_t variable will have "normal
execution" if the variable's value is SSIZE_MAX.  This is regardless
of whether SSIZE_MAX is the maximum value representable in a ssize_t.
So I don't see the point of insisting on a guarantee that SSIZE_MAX
must be the maximum representable ssize_t value.  What can a portable
application do with that guarantee that it couldn't do otherwise?

> With your example of 32-bit int, 64-bit size_t, and SSIZE_MAX = 2**31-1,
> SSIZE_MAX is not larger than an int can hold.

Yes, but it's part of an upgrade path from 'read' returning a a 32-bit
int to 'read' returning a 64-bit ssize_t without changing the ABI
drastically.

> The whole point, surely, was to allow implementations with 16-bit
> int to read and write more than 32K bytes.

Well, at this point we're both guessing.  But my interpretation is
also plausible.  There was considerable concern around 1990, when
POSIX was first written, about the upgrade path from 32-bit machines.
There wasn't that much concern about 16-bit machines any more.