short read/write and error code

Konstantin Belousov kostikbel at gmail.com
Wed Aug 1 07:19:58 UTC 2012


On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote:
> POSIX requires write() to return actually bytes written, same rule is
> applied to read().
> 
> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html
> >ETURN VALUE
> >
> >Upon successful completion, write() [XSI]   and pwrite()  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.
> 
> 
> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html
> >RETURN VALUE
> >
> >Upon successful completion, read() [XSI]   and pread()  shall return
> > a non-negative integer indicating the number of bytes actually read.
> > Otherwise, the functions shall return -1 and set errno to indicate
> > the error.
Note that the wording is only about successful return, not for the case
when error occured. I do think that if fo_read() returned an error, and
error is not of the kind 'interruption', then the error shall be returned
as is.

> 
> I have following patch to fix our code to be compatible with POSIX:
...

> -current only resets error code to zero for short write when code is
> ERESTART, EINTR or EWOULDBLOCK.
> But this is incorrect, at least for pipe, when EPIPE is returned,
> some bytes may have already been written. For a named pipe, I may don't
> care a reader is disappeared or not, because for named pipe, a new
> reader can come in and talk with writer again,  so I need to know
> how many bytes have been written, same is applied to reader, I don't
> care writer is gone, it can come in again and talk with reader. So I
> suggest to remove surplus code in -current's dofilewrite() and
> dofileread().
Then fix the pipe code, and not introduce the behaviour change for all
file types ?

> For EPIPE, We still deliver SIGPIPE to current thread, but returns
> actually bytes written.
And this sounds wrong. I think that fixing the code for pipes would also
semi-magically makes this correct.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120801/6338eb2f/attachment.pgp


More information about the freebsd-arch mailing list