closedir(3) handling NULL

[Konstantin Belousov]

On Fri, Jan 24, 2014 at 11:49:39AM -0600, Bryan Drewery wrote:
> On Fri, Jan 24, 2014 at 07:21:23PM +0200, Konstantin Belousov wrote:
> > 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. POSIX
> > > > > [1] specifies that EBADF should be returned if "The dirp argument does
> > > > > not refer to an open directory stream"
> > > > 
> > > > > [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closedir.html
> > > > 
> > > > > I've updated fdclosedir(3) as well to behave the same.
> > > > 
> > > > > I'll also update the manpage if there is no objection.
> > > > 
> > > > 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.
> > > 
> > > 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 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.
> 
> The code constructed a path, called opendir(3), received NULL, skipped
> over code that uses the entry since it was NULL, then called
> closedir(3).
> 
> Also, I don't find this very different than free(3) with a NULL. It's
> considered bad practice to check for NULL before calling it, why is
> closedir(3) any different?

Ok, so it does not have much to do with unmount, it is just an open
of nonexistent path.

I do not have an answer to the question about free(3), except that
free(NULL) behaviour is required by ANSI C, while closedir(NULL) is not,
by posix.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20140124/36d85625/attachment.sig>