From owner-freebsd-standards@FreeBSD.ORG  Fri Jan 24 20:28:14 2014
Return-Path: <owner-freebsd-standards@FreeBSD.ORG>
Delivered-To: freebsd-standards@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id E2486735
 for <freebsd-standards@freebsd.org>; Fri, 24 Jan 2014 20:28:14 +0000 (UTC)
Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu
 [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id 96CDC15BB
 for <freebsd-standards@freebsd.org>; Fri, 24 Jan 2014 20:28:14 +0000 (UTC)
Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1])
 by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0OKSCM4009010
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA);
 Fri, 24 Jan 2014 15:28:13 -0500 (EST)
 (envelope-from wollman@khavrinen.csail.mit.edu)
Received: (from wollman@localhost)
 by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0OKSCkC009007;
 Fri, 24 Jan 2014 15:28:12 -0500 (EST) (envelope-from wollman)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21218.52444.765847.64846@khavrinen.csail.mit.edu>
Date: Fri, 24 Jan 2014 15:28:12 -0500
From: Garrett Wollman <wollman@csail.mit.edu>
To: Bruce Evans <brde@optusnet.com.au>
Subject: Re: closedir(3) handling NULL
In-Reply-To: <20140125065355.P1644@besplex.bde.org>
References: <20140124014105.GC37334@admin.xzibition.com>
 <20140124132435.GA90996@stack.nl>
 <20140124165509.GA73838@admin.xzibition.com>
 <20140125041504.Y986@besplex.bde.org>
 <21218.48752.949231.855028@khavrinen.csail.mit.edu>
 <20140125065355.P1644@besplex.bde.org>
X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3
 (khavrinen.csail.mit.edu [127.0.0.1]); Fri, 24 Jan 2014 15:28:13 -0500 (EST)
Cc: freebsd-standards@freebsd.org
X-BeenThere: freebsd-standards@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Standards compliance <freebsd-standards.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-standards>, 
 <mailto:freebsd-standards-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-standards/>
List-Post: <mailto:freebsd-standards@freebsd.org>
List-Help: <mailto:freebsd-standards-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-standards>, 
 <mailto:freebsd-standards-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 20:28:14 -0000

<<On Sat, 25 Jan 2014 07:08:33 +1100 (EST), Bruce Evans <brde@optusnet.com.au> said:

> On Fri, 24 Jan 2014, Garrett Wollman wrote:
>> "may fail" has a very specific meaning in the "ERRORS" section: if the
>> implementation detects the condition described, it must use the
>> specified error number.

> That doesn't quite do it.  Detection of the error for closing a closed fd
> is still not required, unlike for fclose().

That is correct.  If the implementation detects this condition and
returns an error, it must indicate [EBADF].  But it need not detect
that condition, even if that will prevent it from performing the
function, and in that case, the function's behavior is unspecified.
Since there are no "shall"s involved, no conformance distinction can
be made between two implementations, one of which detects an invalid
stream and indicates [EBADF], and the other of which does not detect
an invalid stream but turns your computer into a frog.

-GAWollman