Date: Fri, 24 Jan 2014 23:39:18 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Bryan Drewery <bryan@shatow.net> Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: closedir(3) handling NULL Message-ID: <20140124223918.GA97844@stack.nl> In-Reply-To: <20140124213404.GC73838@admin.xzibition.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > This unimproves portability. FreeBSD intentionally does the > > opposite for fclose(): from fclose(3): > IMHO we should handle NULL gracefully in all places instead of having > hidden surprises. 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. Whether a function that frees something silently does nothing when passed a null pointer is indeed inconsistent. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140124223918.GA97844>