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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140125065355.P1644>