closedir(3) handling NULL

[Konstantin Belousov]

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.
-------------- 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/79522d1c/attachment.sig>