> > (b) Why does SSIZE_MAX end up set to the size of > > an int, rather than a 64-bit quantity, on standard > > GNU/Linux header files? This one affects the > > calculation done by failing readv and writev tests > > which are trying to overflow an ssize_t to test the > > error code. But the don't come close, since the > > calulation based on SSIZE_MAX builds 1024 iovs > > of 2,098,176 bytes. > > The kernel readv/writev code which checks this has changed quite a bit > between 2.4 and 2.5. It used to try (but I think it was wrong) to test > when the total read length would overflow a 32 bit int. The 2.5 > behaviour checks for overflow of ssize_t and presumably libc now has > to catch up. I've asked glibc IA64 guy to look at it.
To be clear, the only question I was really asking was why the glibc header seems to define SSIZE_MAX as an int, while ssize_t itself is a long. This doesn't look right. The calculation stuff I refer to is in the test suite, not glibc, and looks okay, except that it performs the wrong calculation since it believes SSIZE_MAX is slightly smaller than is appropriate for a 64-bit machine. :-) Whether it makes sense for the test to continue to try to do what it's doing in the face of a 64-bit ssize_t is a different question - it seems quite a challenge to put together an iov array that will overflow an ssize_t! Mats -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED]
