Date: Fri, 24 Jan 2014 10:55:09 -0600 From: Bryan Drewery <bryan@shatow.net> To: Jilles Tjoelker <jilles@stack.nl> Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: closedir(3) handling NULL Message-ID: <20140124165509.GA73838@admin.xzibition.com> In-Reply-To: <20140124132435.GA90996@stack.nl> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 02:24:35PM +0100, Jilles Tjoelker wrote: > On Thu, Jan 23, 2014 at 07:41:05PM -0600, Bryan Drewery wrote: > > I found that Linux handles closedir(NULL) fine and returns EINVAL. POSIX > > [1] specifies that EBADF should be returned if "The dirp argument does > > not refer to an open directory stream" >=20 > > [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closedir.h= tml >=20 > > I've updated fdclosedir(3) as well to behave the same. >=20 > > I'll also update the manpage if there is no objection. >=20 > If you do this, it is to improve compatibility with poorly written > software and not for POSIX compliance. POSIX only permits passing null > pointers where explicitly specified (e.g. time()); otherwise, passing a > null pointer is undefined behaviour like passing any argument outside > the required domain. I do think that improving portability is important. Even against sloppy coding. Applications developed for Linux are fine passing NULL to closedir(= 3), which leads to a style of coding that does not reveal itself to be a problem on FreeBSD until an edge case comes up. This is the situation to led to me find this. A mountpoint disappeared and some code written for Linux, that ported to FreeBSD without changes, segfaulted in closedir(3). >=20 > On another note, I don't understand when the condition > [EBADF] The dirp argument does not refer to an open directory stream. > can actually apply. As far as I understand, only valid open directory > streams (opendir() has been called and closedir() has not been called) > may be passed to closedir() and other functions. If the pointer is not a > null pointer, detecting whether it refers to a valid open directory > stream is not possible using common methods (you could maintain a list > of directory streams but doing that is against the spirit of C and I am > quite sure that POSIX did not intend to require implementations to do > that). I was wondering that as well and whether EBADF really made sense, sicne it was not validating the pointer was from opendir(3). >=20 > In the current code in FreeBSD, [EBADF] may also happen if an > application closes a directory stream's file descriptor from under it > and no other file descriptor is opened in its place. >=20 > In some cases like the file_name argument to realpath(), NULL is > specified to cause an [EINVAL] return; I think we are stuck with that > but should not add more such cases. Note that this [EINVAL] return also > means that realpath(NULL, p) is valid to do and should not trigger > undefined behaviour detectors.. I'm not clear where you stand on this. Is EINVAL more proper or EBADF, or are you against the change all together? I find this sort of seat belt good for portability and of little harm. >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-standards@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-standards > To unsubscribe, send any mail to "freebsd-standards-unsubscribe@freebsd.o= rg" --FCuugMFkClbJLl1L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS4prsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNkZFQkU5OTJGNTI4MERGNDgxMTM2MkE2 RTc4MkFDMDNDOUIwQ0Y5AAoJEG54KsA8mwz5qZkP/2C2d6jzCNaTb38rozmrn3Dh 3amJWwgwokWv0oQOOiuW3mAPx74JkWrg9cwc3f9FASvSDl+ZP6y5jOc2ZcndTBuI wPWvdxcmK+kjUrXaG72mARjtQc5Ozf9eB6FP5wwP29i+uHGDqDscVcHnbR48oGNN f4EcoK+QHrgJj+d/LpEtwYgjUz5zQSWQWbTAFrJ0Ne/JCSKZ647Cv4PI7uSp45AE 9D2dzth/5m65IfROu9Ts6zf9rJi2/qeQN9KfVCIs18u4HCWclJmPGKKWkeQD/AwR RWTHZAMFsIQ0xOXrXwtWj9cjLA4cV+CkradUmJjrG4DU9ihBF8Y8F6B7kF4yPk63 r0B7W9lOOQ0mOVVBgj0Bb0Ny93Fyrd0gNZPnkjvOpGpOcOXe6zCiPdH/c2SIt7AS uhYmP1UCeELaSxqvMEV+mq3oDjKKlHb61CF3En9kNFd/JP7/MXHK/Ja5OMNVknNL Ljj/iRVcILwNc/jPdGf21d96ylFEEofme5Q7+iKu9Z2+AmgLeDQbSrnGWEi7NSC/ p79Vn/DQnI+VHPzEAvhzA3DOTd/UF3SD9FUC3X7EuMq1szQR4Vcs7IM6nkj7BoNu mJM+C5AF9zhBdUuaik9ZRP3U7ipMF3FaxX9NWBuOOX0EKcyBkSza24cahZHA5pTj WsiMyuBPf8v7F+Q1ybKC =vRNN -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140124165509.GA73838>