Re: source(builtin) and read(2)

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[originally mentioned on bug-bash]

According to Matthew Woehlke on 3/23/2007 3:40 PM:
> Eric Blake wrote:
>> According to Matthew Woehlke on 3/23/2007 2:40 PM:
>>>> SSIZE_MAX is guaranteed to be the maximum value that fits in ssize_t.
> 
> ...that "fits", or that "may be stored in"?
> 
>>>> Again, if your ssize_t is smaller than 32 bits, your platform has other
>>>> issues.  Just because POSIX allows ssize_t to be as small as 16 bits
>>>> doesn't mean many modern platforms do that.
>>> Hmm... well then I guess this is broken:
>>> /usr/include/limits.h:#define SSIZE_MAX        53248    /* max single
>>> I/O size, 52K       */
>>
>> Which platform is this?
> 
> NSK, naturally. :-)
> 
>>  Yes, it is horribly broken; it's not even one
>> less than a power of two, which means it is an outright violation of
>> this:
>> http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
>> {SSIZE_MAX}
>>     Maximum value of an object of type ssize_t.
>>     Minimum Acceptable Value: {_POSIX_SSIZE_MAX}
> 
> I'm not convinced. That says "Implementations may choose any appropriate
> value for each limit, provided it is not more restrictive than the
> Minimum Acceptable Values listed below", and, in this case and *only*
> this case, includes the words "...of an object...". While I admit one
> might *expect* SSIZE_MAX to refer to the largest /representable/ value,
> I don't see (from just that document) what prevents reading it as the
> largest /permissible/ value (which is clearly the interpretation NSK
> chose).

This has potentially severe ramifications to a number of gnulib-based
projects.  I'm seeking backup from those more knowledgeable about the C
and POSIX standards as to whether NSK is allowed to define SSIZE_MAX to
something smaller than what the underlying type can hold, and if so,
whether it is worth auditing gnulib to find any places that have
previously assumed that SSIZE_MAX is ((1<<(sizeof(ssize_t)*CHAR_BIT -
2))-1)*2+1.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGBE8N84KuGfSFAYARAtXUAKCdN1RpU+KNt2XqkvzqU2T7Uu5HqwCgz5VP
KDx8DqCsrplop9tQ68/Bepc=
=KYLa
-----END PGP SIGNATURE-----