From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 16:55:21 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45529C6B for ; Fri, 24 Jan 2014 16:55:21 +0000 (UTC) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCF291269 for ; Fri, 24 Jan 2014 16:55:20 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sweb; b=dqBK6YFexjwPMUGXZsft1h5+FVpeabXuX 7h2bBbXI7QS5/rG1JqN1jyHilnwHi3fC3NSXBmKrMWXBRShkWKzcUDHxL78zyz1B kfy591SD4z8Ydi9+exHW9WJg3QynKciBilErn5kwbfMxNp1I/qUh9BMsAzom6B2r VZwZnXK3ec= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=sweb; bh=5BaqH8iyAMsOcAr8VupyZc3SHxebeI1YrWV74Ht BK1c=; b=omgIv12VMb0WNe+GRIeW+EdZb/n/prgUjnO6f3YvnSrldx/6OL2C6YX k0idMEcGZ/TZMHGiwP3+27+efQlBh3T247Q41WJhWDVJlaaaPZ6dL9OspT5HiLrL XkrqORe1qJnuuJEf4rWiGU85wQdVErmHbByUGYR7uyzj/NlqKM10= Received: (qmail 50074 invoked from network); 24 Jan 2014 10:55:13 -0600 Received: from unknown (HELO admin.xzibition.com) (bryan@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 24 Jan 2014 10:55:13 -0600 Date: Fri, 24 Jan 2014 10:55:09 -0600 From: Bryan Drewery To: Jilles Tjoelker Subject: Re: closedir(3) handling NULL Message-ID: <20140124165509.GA73838@admin.xzibition.com> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20140124132435.GA90996@stack.nl> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: bapt@FreeBSD.org, 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 16:55:21 -0000 --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--