Bug#629994: sendfile returns early without user-visible reason
On Fri, Jun 10, 2011 at 12:15:44PM +0200, Marc Lehmann wrote:
> On Fri, Jun 10, 2011 at 03:21:38AM -0500, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Indeed, read(2) does the same thing (truncates to 7ffff000) and has done
> 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?
> > Background: even with read(2) and write(2), partial progress does not
> > necessarily represent an error.
> Thats true _in general_, but in posix/unix/sus it has clearly defined
> and user-visible semantics for that,
| Upon successful completion, write() shall return the number of bytes
| actually written to the file associated with fildes. This number shall
| never be greater than nbyte. Otherwise, -1 shall be returned and errno
| set to indicate the error.
> which require that the success case
> transfers as many bytes as can be transferred, and not stop a random
> amount earlier
Please quote the standard on this. Please note that A => B does not
imply !A => !B (A == {not-regular, signaled}, B == short-write).
> This works fine as long as the OS follows posix.
Linux is no fully compliant POSIX system.
Bastian
--
Pain is a thing of the mind. The mind can be controlled.
-- Spock, "Operation -- Annihilate!" stardate 3287.2
Reply to: