Bug#629994: sendfile returns early without user-visible reason
On Fri, Jun 10, 2011 at 02:29:46PM +0200, Bastian Blank <waldi@debian.org> wrote:
> > What the fuck, it's buggy, indeed:
> > read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 3298534883328) = 2147479552
>
> What is the bug?
Please *read* the bug report.
> > transfers as many bytes as can be transferred, and not stop a random
> > amount earlier
>
> Please quote the standard on this.
Please *read* the bug report. You can also read the full read(2) sus
manpage online at www.opengroup.org.
> Please note that A => B does not imply !A => !B (A == {not-regular,
> signaled}, B == short-write).
Reading standards is notoriously difficult, I admit. The behaviour of read
is specified to read the requested number of bytes, if possible.
The standard gives an exception list where applications can deviate from
the behaviour and read less.
For other exceptions, you would have to find a part of the standard that
actually allows it.
So where in the standard is this read behaviour allowed?
> > This works fine as long as the OS follows posix.
>
> Linux is no fully compliant POSIX system.
This is painfully clear. It's also not a unix kernel.
What should be clear to you though, is that posix semantics for read that a
lot of real world programs rely on is useful regardless of whether it is
specified in posix or not, and regardless of whether it is specified
What you also totally miss is that this is also historical unix behaviour,
and linux *is* a unix kernel clone.
If you actually had read the full bug report you could have known that
already.
> Bastian
Please, next time, actually try to read the bug report before sending a
superfluous mail, it just wastes time for those people interested.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
Reply to: