Paul Eggert <[EMAIL PROTECTED]> wrote, on 29 Mar 2007:
>
> My vague recollection is that ssize_t and SSIZE_MAX were put in
> precisely to support screwy implementations like Tandem. But
> this was a while ago and I wasn't there, so I could well be wrong.
The ssize_t type was introduced (in 1990) in order to allow read()
and write() to read and write more than INT_MAX bytes. This is clear
from the rationale for read():
"The use of I/O with large byte counts has always presented
problems. Ideas such as lread() and lwrite() (using and returning
longs) were considered at one time. The current solution is to
use abstract types on the ISO C standard function to read() and
write(). The abstract types can be declared so that existing
functions work, but can also be declared so that larger types can
be represented in future implementations. It is presumed that
whatever constraints limit the maximum range of size_t also limit
portable I/O requests to the same range. This volume of IEEE Std
1003.1-2001 also limits the range further by requiring that the
byte count be limited so that a signed return value remains
meaningful. Since the return type is also a (signed) abstract
type, the byte count can be defined by the implementation to be
larger than an int can hold."
As regards the original question, my interpretation is that the
description of SSIZE_MAX in <limits.h> ("Maximum value of an object of
type ssize_t") places exactly the same requirements on the value of
SSIZE_MAX as would the description "Maximum value of type ssize_t".
The use of "an object of" has no significance.
If the following code:
ssize_t var;
var = SSIZE_MAX;
++var;
if (var > SSIZE_MAX)
puts("SSIZE_MAX wrong");
outputs "SSIZE_MAX wrong" on any implementation, then var is an object
of type ssize_t which was able to contain a value greater than
SSIZE_MAX, and therefore the implementation's definition of SSIZE_MAX
does not conform to the standard.
--
Geoff Clare <[EMAIL PROTECTED]>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
