-----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 [EMAIL PROTECTED] -----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-----
