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).
Regardless, I'd still like bash to work here.
--
Matthew
Excessive obscurity: -5
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
