Date: Fri, 24 Jan 2014 19:29:32 -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: <20140125012932.GD73838@admin.xzibition.com> In-Reply-To: <20140124223918.GA97844@stack.nl> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140125041504.Y986@besplex.bde.org> <20140124213404.GC73838@admin.xzibition.com> <20140124223918.GA97844@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--SFyWQ0h3ruR435lw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 11:39:18PM +0100, Jilles Tjoelker wrote: > On Fri, Jan 24, 2014 at 03:34:04PM -0600, Bryan Drewery wrote: > > On Sat, Jan 25, 2014 at 06:00:08AM +1100, Bruce Evans wrote: > > > On Fri, 24 Jan 2014, Bryan Drewery wrote: > > > > 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. >=20 > > > This unimproves portability. FreeBSD intentionally does the > > > opposite for fclose(): from fclose(3): >=20 > > IMHO we should handle NULL gracefully in all places instead of having > > hidden surprises. >=20 > In many cases (but possibly not this one), handling NULL "gracefully" > makes it harder to debug the inevitable failure. For example, if > readdir() did not crash when passed a null pointer, a program that fails > to check opendir()'s return value would plough on for longer and it > would be harder to find the problem. >=20 > Whether a function that frees something silently does nothing when > passed a null pointer is indeed inconsistent. This argument makes sense to me. Stating the obvious, it's unfortunate that POSIX leaves some behavior undef= ined that leads to these inconsistencies between systems. >=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" --SFyWQ0h3ruR435lw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS4xN8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNkZFQkU5OTJGNTI4MERGNDgxMTM2MkE2 RTc4MkFDMDNDOUIwQ0Y5AAoJEG54KsA8mwz5sV4P/iiOf4w8vbkIy760kwjIQKDl oViICQsLTcHFu0HwSZaL/Gbg7O83pJQjxw8/oXCg4O3YhBxgmhEyOH7UFnE9wxKe +Sjd646xLhI/h9l4HDn4Tf0YsFoa+OINllNgakmuZry1v8+GwbMu38P0hXhgF8RR CPepPLgCDsWVXfnNnHwSiYMrVd8oCRRPSsgIX6fgwEudRIThzYdJBaRomUbzy5sG nNySRHZqShx5daVw3QszBaHEl/4OA2FdqSP66UZaT7i8f4JFRu3tbYWavkGSkQwp GCjRS/coOX0nzASansT9LqEhr4oQFSJQNYLI7hfVs7BCjQHCqOKU3l0r1DZUlx2O FcxXmcBEXdeRZfYQeq0787MvwJUf4Nrkxrghk4Di7+w97Fy3M9cDRcNIw9skwF8D dDrYUE4JnPrmW0eZBWLqt3RdRnIyJUV3d4FFvPPNHNfZRnkAP6XMZ3Ak3q2b+ghp 3iMPnBGIm3d25oR5ql4EVUU/xfKCcoWKAO+ZEuOLBOltEQxKeWGAasMKQyTvNIBy MKjxFmn3E9aLPfEqPhsd4wCY6uhRsTmu41Fg3+kcCqxz5h9VTH1skX7YFEZ72FED I5AECfDK47uYR43nOnSrL1RPy4odSnf6E+XqpankEoAnzKlGkh1ILwbe4UUiu/i0 GzeQNrnhWogQADAvKsKk =lcLW -----END PGP SIGNATURE----- --SFyWQ0h3ruR435lw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140125012932.GD73838>