From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 20:28:24 2014 Return-Path: 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 7F049758 for ; Fri, 24 Jan 2014 20:28:24 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE2015BC for ; Fri, 24 Jan 2014 20:28:23 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id D9AC442456F; Sat, 25 Jan 2014 07:08:51 +1100 (EST) Date: Sat, 25 Jan 2014 07:08:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Wollman Subject: Re: closedir(3) handling NULL In-Reply-To: <21218.48752.949231.855028@khavrinen.csail.mit.edu> Message-ID: <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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=FLjmdRbynEcA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=s-lAilbsuXwA:10 a=ADeeF_SfVXO_LmrnBxMA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:28:24 -0000 On Fri, 24 Jan 2014, Garrett Wollman wrote: > < said: > >> I don't know how the fd can be invalid for a (necessarily valid) stream. >> Maybe because the fd for a stdio stream is not private, and POSIX actually >> allows closing it directly. At least this says "shall fail" instead of >> "may fail". I think the "may fail" for closedir() is just buggy wording. >> The "may" is for the implementation not being required to use fd's at all. >> But when it uses them, errors from them should be "shall fail" like they >> are for fclose(). > > "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(). I could only find the above implied indirectly, and not completely. % 435 RETURN VALUE % 436 This section indicates the possible return values, if any. % 437 If the implementation can detect errors, ``successful completion'' means that no error % 438 has been detected during execution of the function. If the implementation does detect % 439 an error, the error is indicated. So if an error is detected, that error is "indicated". I think the indication must be in the usual way, by storing in errno (except for these unsual APIs where it is returned). This is already inconsistent with returning a specific error. I think nothing prevents detection of a different error (one not even listed in the ERRORS section) and nothing prevents returning that error, while the above requires it. % 440 For functions where no errors are defined, ``successful completion'' means that if the % 441 implementation checks for errors, no error has been detected. If the implementation can % 442 detect errors, and an error is detected, the indicated return value is returned and errno % 443 may be set. The only thing that is clear is that if an error is detected, the function cannot succeed. Bruce