tags 533232 fixed-upstream
thanks
On Mon, Jun 15, 2009 at 9:12 PM, Zack Weinberg <za...@panix.com> wrote:
> Package: manpages-dev
> Version: 3.21-1
> Severity: minor
>
> The read(2) manpage currently says
>
> If _count_ is zero, read() returns zero and has no other results.
>
> but this does not explain what happens if the _fd_ or _buf_ parameters are
> invalid (== would cause an error return or a segmentation fault if _count_
> were nonzero).
>
> I experimented and found that Linux returns -1/EBADF if count is zero but
> fd refers to a file descriptor that is not open; all the other cases I can
> trivially test (read 0 bytes from an fd open for writing only, read 0 bytes
> with an invalid buffer pointer) do return 0 and leave errno untouched.
>
> I do not, however, know if this behavior can be relied on in portable code.
> (If not, it might be nice to mention that fcntl(fd, F_GETFL, 0) is a portable
> way to determine whether 'fd' is an open file descriptor.)
Zack,
POSIX deliberately leaves the behavor here open. The read(3p) page says:
Before any action described below is taken, and if nbyte is
zero, the read() function may detect and return errors as
described below. In the absence of errors, or if error detec‐
tion is not performed, the read() function shall return zero
and have no other results.
I've adjusted the text in the Linux read(2) page, replacing:
If count is zero, read() returns zero and has no other results.
with
If count is zero, read() may detect the errors described below.
In the absence of any errors, of if read() does not check for
errors, a read() with a count of 0 returns zero and has no
other effects.
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
