[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: coreutils-8.14.116-1e18d on NetBSD 5.1 - split bug
From: |
Pádraig Brady |
Subject: |
Re: coreutils-8.14.116-1e18d on NetBSD 5.1 - split bug |
Date: |
Thu, 05 Jan 2012 13:10:31 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 |
On 01/05/2012 12:27 PM, Bruno Haible wrote:
> Pádraig Brady wrote:
>> I wonder should full_read() be adjusting the errno?
>> I.E. maybe the behavior of read() and full_read() should
>> be different, as the latter can do a successful partial read(),
>> and then have a failure. So it should be possible to assume
>> n_read >-1 and a valid errno?
>
> Of course read() and full_read() have different return conventions, for
> precisely the reason that you cite. But that's not a reason to set errno
> always. POSIX functions set errno only in case of specific conditions
> that you can check after the function returned. full_read() is designed
> in the same spirit. If gnulib defined functions were to set errno always,
> that would be an inconsistency between POSIX and gnulib.
>
> The return convention of full_read() is perfectly well documented:
>
> /* Read COUNT bytes at BUF to descriptor FD, retrying if interrupted
> or if partial reads occur. Return the number of bytes successfully
> read, setting errno if that is less than COUNT. errno = 0 means EOF. */
> extern size_t full_read (int fd, void *buf, size_t count);
>
> Nothing to do there.
Agreed.
So for read(), errno is only valid when -1 returned.
and for full_read(), errno is only valid when < bufsize returned.
cheers,
Pádraig.