closedir(3) handling NULL
bryan at shatow.net
Sat Jan 25 01:29:36 UTC 2014
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.
> > > 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.
This argument makes sense to me.
Stating the obvious, it's unfortunate that POSIX leaves some behavior undefined
that leads to these inconsistencies between systems.
> Jilles Tjoelker
> freebsd-standards at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-standards-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 964 bytes
Desc: not available
More information about the freebsd-standards