[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnulib-bug
Subject:    RE: source(builtin) and read(2)
From:       "Matthew Woehlke" <mwoehlke () tibco ! com>
Date:       2007-03-26 19:24:55
Message-ID: E4B46A50CCA52348A67B3506C79BB39048AC4B () NA-PA-VBE01 ! na ! tibco ! com
[Download RAW message or body]

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. :-)

--=20
Matthew



[prev in list] [next in list] [prev in thread] [next in thread]