[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: source(builtin) and read(2)
From: |
Eric Blake |
Subject: |
Re: source(builtin) and read(2) |
Date: |
Sat, 24 Mar 2007 07:50:30 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.666 |
-----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-----
- Re: source(builtin) and read(2), Eric Blake, 2007/03/23
- Re: source(builtin) and read(2), Paul Eggert, 2007/03/23
- Re: source(builtin) and read(2), Bruno Haible, 2007/03/23
- Re: source(builtin) and read(2),
Eric Blake <=
- RE: source(builtin) and read(2), Schwarz, Konrad, 2007/03/26
- Re: source(builtin) and read(2), Clive D.W. Feather, 2007/03/26
- RE: source(builtin) and read(2), Schwarz, Konrad, 2007/03/26
- Re: source(builtin) and read(2), Clive D.W. Feather, 2007/03/26
- RE: source(builtin) and read(2), Nick Stoughton, 2007/03/27
- Re: source(builtin) and read(2), Clive D.W. Feather, 2007/03/27
- Re: source(builtin) and read(2), Matthew Woehlke, 2007/03/27
- RE: source(builtin) and read(2), Matthew Woehlke, 2007/03/27
- Re: source(builtin) and read(2), Paul Eggert, 2007/03/29
- Re: source(builtin) and read(2), Geoff Clare, 2007/03/30