Nick Stoughton wrote: > As to the original question ... can a system that implements ssize_t > with a SSIZE_MAX of 56k conform to POSIX? As far as I can see, I don't > see why not. I agree that it is unnatural, but I can find nothing that > prohibits it. Most (if not all) interfaces that return ssize_t values > state that the results are implementation defined if you ask for more > than SSIZE_MAX bytes. If their implementation defines that a read of > >56k returns -1, then absolutely, they are conforming. If their > implementation defines that a read of >56k+1 returns >56k (assuming > that there was that much data available), then they are in slightly > more murky waters ... since the resulting value, while storable in an > object of sizeof(ssize_t) is not a legal member of the class of values > that may be stored in the object. And in that case, why did they > choose to make SSIZE_MAX this strange value in the first place?
...the obvious guess here would be that this is some sort of I/O limit related to either the kernel implementation or possibly the underlying file system layers. Presumably such a limitation could be overcome by a complicated implementation of read(); I guess OSS just doesn't bother jumping through such hoops, since POSIX does not require it. :-) -- Matthew
