From owner-svn-src-all@FreeBSD.ORG Mon Jun 15 21:25:48 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50FE71065B74; Mon, 15 Jun 2009 21:25:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 23CE28FC29; Mon, 15 Jun 2009 21:25:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CA83D46B29; Mon, 15 Jun 2009 17:25:47 -0400 (EDT) Date: Mon, 15 Jun 2009 22:25:47 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200906151709.55435.jhb@freebsd.org> Message-ID: References: <200906152038.n5FKctaR001026@svn.freebsd.org> <4A36B3E2.7060309@freebsd.org> <200906151709.55435.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Colin Percival Subject: Re: svn commit: r194262 - in head: include lib/libc/sys sys/compat/freebsd32 sys/kern tools/regression/file/closefrom X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 21:25:49 -0000 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