At 2002/7/29 22:21-0700 Wichmann, Mats D writes: > > 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.
Oh sure, I agree it looks wrong. What I was trying to say was the SSIZE_MAX setting *might* have been intentional because its approximately (plus or minus a bug or two) what the 2.4 kernel readv/writev supports (tried to support) even on 64 bit platforms with a bigger ssize_t (it looked for 32 bit overflow). No reason why SSIZE_MAX can't be bigger, but the 2.5 code will need to be backported to 2.4. Chris -- [EMAIL PROTECTED] IBM OzLabs Linux Development Group Canberra, Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED]
