Date: Mon, 15 Jun 2009 17:09:54 -0400 From: John Baldwin <jhb@freebsd.org> To: Colin Percival <cperciva@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r194262 - in head: include lib/libc/sys sys/compat/freebsd32 sys/kern tools/regression/file/closefrom Message-ID: <200906151709.55435.jhb@freebsd.org> In-Reply-To: <4A36B3E2.7060309@freebsd.org> References: <200906152038.n5FKctaR001026@svn.freebsd.org> <4A36B3E2.7060309@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906151709.55435.jhb>