-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. >> 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? 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} > > The man page here says: > If the value of nbytes is greater than SSIZE_MAX, > the read() function returns -1 and sets errno to > [EINVAL]. > > ...and trust me, it ain't lying. This broke at least gawk and gzip, and > even the Linux man page seems to strongly indicate that you should pay > attention to SSIZE_MAX when calling read(). Except that usually SSIZE_MAX is one-half of SIZE_MAX, which is usually the same size as pointers. On Linux, it is relatively rare to try to read more than 2 gigabytes in a single read() call. You usually run into other platform limitations before it is possible to exceed the SSIZE_MAX limitation. - -- 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 iD8DBQFGBEGw84KuGfSFAYARAvJeAJ4tAWack3ds75zDKUIBtkDyOtdIqgCfV5Ng tyZ470ICG5VhuiHotUpQI2g= =y26D -----END PGP SIGNATURE----- _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
