coreutils
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]