Date: Sat, 25 Jan 2014 07:08:33 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Garrett Wollman <wollman@csail.mit.edu> Cc: freebsd-standards@freebsd.org Subject: Re: closedir(3) handling NULL Message-ID: <20140125065355.P1644@besplex.bde.org> In-Reply-To: <21218.48752.949231.855028@khavrinen.csail.mit.edu> 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>
index | next in thread | previous in thread | raw e-mail
On Fri, 24 Jan 2014, Garrett Wollman wrote: > <<On Sat, 25 Jan 2014 06:00:08 +1100 (EST), Bruce Evans <brde@optusnet.com.au> 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. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140125065355.P1644>