closedir(3) handling NULL

[Bryan Drewery]

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
> http://lists.freebsd.org/mailman/listinfo/freebsd-standards
> To unsubscribe, send any mail to "freebsd-standards-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 964 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20140124/b2037d8c/attachment-0001.sig>