RE: Itanium size-related tests
> > (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 lsb-test-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
Reply to: