Re: source(builtin) and read(2)

[Eric Blake]

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

Let's take this question to the Austin group, for a definitive word from
the POSIX folks.  The question originally arose on the bash mailing lists
(http://lists.gnu.org/archive/html/bug-bash/2007-03/msg00067.html and
following, see also
http://lists.gnu.org/archive/html/bug-gnulib/2007-03/msg00315.html).

>>>>> 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. :-)
> 

>>> 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).

The question is whether NSK can ever claim POSIX compliance with its
current definition of SSIZE_MAX at 52k, which is much smaller than
((1<<(sizeof(ssize_t)*CHAR_BIT-2))-1)*2+1, but still larger than
_POSIX_SSIZE_MAX.

One the one side, Paul Eggert pointed out:
> Yes, that's my understanding.  To back this up,
> <http://www.opengroup.org/susv3/basedefs/sys/types.h.html> says "The
> type ssize_t shall be capable of storing values at least in the range
> [-1, {SSIZE_MAX}]" which has the clear implication that ssize_t might
> be able to store values greater than SSIZE_MAX.

On the other side, Bruno Haible retorted:
> I'm less knowledgeable than Paul, but I would say that 52*1024 is not an
> "appropriate" value for SSIZE_MAX. Because if you say that it is, then the
> sentence
>    "{SSIZE_MAX}
>            Maximum value of an object of type ssize_t."
> is void - the standard authors might then have defined SSIZE_MAX as
>     "The maximum I/O transfer size"
> or  "A value of type ssize_t".

In other words, it seems inconsistent that this is the one *_MAX constant
that is allowed to be less than what the underlying type holds, although
there are few enough standard APIs that use ssize_t that it may be intended.

- --
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

iD8DBQFGBSyl84KuGfSFAYARAjfEAKCHu5hQG8uN8Jp5cAfpPbghxLquOACcDHgz
RZqLdzquqSPwJAmSZT8RXYI=
=F5FP
-----END PGP SIGNATURE-----