From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/204
Path: news.gmane.org!not-for-mail
From: Vasiliy Kulikov <segoon@openwall.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: close(2) failure cases (was: some fixes to musl)
Date: Sun, 24 Jul 2011 21:49:03 +0400
Message-ID: <20110724174901.GA3219@albatros>
References: <20110721170255.GA7352@albatros>
 <20110721182101.GB132@brightrain.aerifal.cx>
 <20110724091918.GA6076@albatros>
 <20110724122402.GH132@brightrain.aerifal.cx>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: lo.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: dough.gmane.org 1311530433 394 80.91.229.12 (24 Jul 2011 18:00:33 GMT)
X-Complaints-To: usenet@dough.gmane.org
NNTP-Posting-Date: Sun, 24 Jul 2011 18:00:33 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-288-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 24 20:00:28 2011
Return-path: <musl-return-288-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@lo.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by lo.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-288-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1Ql2yU-0001tv-Qc
	for gllmg-musl@lo.gmane.org; Sun, 24 Jul 2011 20:00:22 +0200
Original-Received: (qmail 17455 invoked by uid 550); 24 Jul 2011 18:00:22 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 17447 invoked from network); 24 Jul 2011 18:00:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=sender:date:from:to:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        bh=fZS0fIoDDzeYU5gmPYGTA9pz6lqp27Nu5P9eW4i7O2c=;
        b=UvMHb4l9NM863gFF1UqXOL5DH8P8ZjH/sFanOF1Glr6HGtHBAUMsqTA9EmPxMNA6mV
         3dLmiZlVzm7vxsjFh0jpC4vVzkYqo4xlANmplidMV2sk3WPfaCveSyB2OugN06erHqhy
         1x4IJlX9F6zVT5161kEYqxtd5DlUJleGghSYw=
Original-Sender: Vasiliy Kulikov <segooon@gmail.com>
Content-Disposition: inline
In-Reply-To: <20110724122402.GH132@brightrain.aerifal.cx>
User-Agent: Mutt/1.5.20 (2009-06-14)
Xref: news.gmane.org gmane.linux.lib.musl.general:204
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/204>

Rich,

On Sun, Jul 24, 2011 at 08:24 -0400, Rich Felker wrote:
> > Even if close() fails, the fd is freed.  So fd leakage is impossible.
> 
> Is this true even in the case of EINTR?

For all types of fd the fd is deleted from fd table, then
FS-specific function is called.  Any error would be returned to the
program, but fd would be already deregistered.


I agree with POSIX in part that close() should somehow signal about
failed IO (e.g. no free disk space) and error return code is good
enough.  However, I feel it was wrong to leave undefined behaviour of fd in
case of error.  If the file is so important that the error must be
handled by the program, it really should do *sync() and react on its
error.  IMO close() should unconditionally close fd.  (The same for
fclose(3), etc.)

Thanks,

-- 
Vasiliy