From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 17:21:32 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 94A8B662; Fri, 24 Jan 2014 17:21:32 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B181414BA; Fri, 24 Jan 2014 17:21:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s0OHLND5059900; Fri, 24 Jan 2014 19:21:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s0OHLND5059900 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s0OHLNP7059899; Fri, 24 Jan 2014 19:21:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Jan 2014 19:21:23 +0200 From: Konstantin Belousov To: Bryan Drewery Subject: Re: closedir(3) handling NULL Message-ID: <20140124172123.GK24664@kib.kiev.ua> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lildS9pRFgpM/xzO" Content-Disposition: inline In-Reply-To: <20140124165509.GA73838@admin.xzibition.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org, Jilles Tjoelker 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 17:21:32 -0000 --lildS9pRFgpM/xzO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 10:55:09AM -0600, Bryan Drewery wrote: > 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. PO= SIX > > > [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= =2Ehtml > >=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. >=20 > I do think that improving portability is important. Even against sloppy > coding. Applications developed for Linux are fine passing NULL to closedi= r(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. >=20 > 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). This is somewhat strange description of events, it definitely misses some intermediate steps. The mere fact of unmounting does not change anonymous memory content of some application. Even if the DIR * was assotiated with the directory descriptor belonging to the disappeared mount point, the DIR * and file descriptors are still valid, although not that functional. --lildS9pRFgpM/xzO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS4qESAAoJEJDCuSvBvK1B/LUP/AgSoBHbnGylaKayoZG3LTLq 7T984ni+CrvrUQ+r/Mtfv69TdofmbhelWEDCocRqd75LULVn/M4ZOq8lt2RV3NP3 VN7Bd9Z3qegxL+tVH1tEjfwQ+RHbwVkbodOfcFzn8/0M5Qi7N0k6rdSTPGyeJmx0 uCKiEKE4hDXSRveb4Pghbh6PH4CXJWfYXI7/+sS4KQpr9TGUL4FkDvi2zsiAsqsH nd3UVUHVzMDShbjPw5XSw0mxdGTj9Pob5R4COjA7b1gsgTup3LvfddtJDwEWn2Z/ bW61/inV8ROe9hl2memrEK8cJnOqZIjefms8Asj+YymOzVoVWLJDW4Amfr2rnsiC fTSzJKoqqEzvWtpdiEfPmLehtuK9e1Sk72cr5iiw5PIJz8wJMHwkCXH7JW9bfZcP 5AKGDkdmimvV+eRoSBvgfJn16gpmjx5sldRE/f7JrUaytt2FlmwPUSIwhWInNZg/ wOBK+Zl5pkGp826b0XLXvQPgOnHOZzDSLXbCB2n4TEv3i9sUkcpfL1qCcvAhY4Zd gpVfU+vSe0ocvl6uAVm88Nnh3zbm/fXYbM4DV3wdM2JsyOcj6FAN2AjtfGkMRcuh WbNzQxjHZ5q14S0xt35Av6t/ACS2DV+2Dq/kvSBRrqMRDFsBsReFjStg1GpHsCYm PdL9cT+moz9JVNi65+DP =jNjw -----END PGP SIGNATURE----- --lildS9pRFgpM/xzO--