svn commit: r194262 - in head: include lib/libc/sys sys/compat/freebsd32 sys/kern tools/regression/file/closefrom

[Robert Watson]

On Mon, 15 Jun 2009, John Baldwin wrote:

> On Monday 15 June 2009 4:49:38 pm Colin Percival wrote:
>> John Baldwin wrote:
>>>   One difference from other *BSD is that this closefrom() does not
>>>   fail with any errors.  In practice, while the manpages for NetBSD and
>>>   OpenBSD claim that they return EINTR, they ignore internal errors from
>>>   close() and never return EINTR.  DFly does return EINTR, but for the common
>>>   use case (closing fd's prior to execve()), the caller really wants all
>>>   fd's closed and returning EINTR just forces callers to call closefrom() in
>>>   a loop until it stops failing.
>>
>> Wouldn't it be better for portability if closefrom(2) is defined to return an
>> int, even if the value returned is always zero?  Otherwise people who want to
>> write code which works on all BSDs end up having to do something like
>> #ifdef __FreeBSD__
>> 	closefrom(x);
>> #else
>> 	while (closefrom(x))
>> 		continue;
>> #endif
>
> Solaris returns void, so we just end up in their #ifdef vs the other. 
> Also, Robert's belief is that the vast majority of existing code doesn't do 
> a loop correctly, but instead just does a single call to closefrom(x).  In 
> that case, ignoring errors gives the best chance of working correctly.

To me, interrupting the loop on EINTR doesn't make much sense, as it means 
applications would always use:

 	do {
 		ret = closefrom(x);
 	} while (ret < 0);

Since the desirable idiom is rarely "close until you hit one that EINTRs, in 
which case abort but don't tell me which one it was".  I find it equally 
likely for other errno values sometimes returned -- EIO, etc.  If you want to 
close one file descriptor and reliably collect error-on-close, you must use 
close(2).  Non-deterministic file descriptor closing seems... unuseful.

Robert N M Watson
Computer Laboratory
University of Cambridge