closedir(3) handling NULL

[Bryan Drewery]

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).

> 
> On another note, I don't understand when the condition
> [EBADF] The dirp argument does not refer to an open directory stream.
> can actually apply. As far as I understand, only valid open directory
> streams (opendir() has been called and closedir() has not been called)
> may be passed to closedir() and other functions. If the pointer is not a
> null pointer, detecting whether it refers to a valid open directory
> stream is not possible using common methods (you could maintain a list
> of directory streams but doing that is against the spirit of C and I am
> quite sure that POSIX did not intend to require implementations to do
> that).

I was wondering that as well and whether EBADF really made sense, sicne
it was not validating the pointer was from opendir(3).

> 
> In the current code in FreeBSD, [EBADF] may also happen if an
> application closes a directory stream's file descriptor from under it
> and no other file descriptor is opened in its place.
> 
> In some cases like the file_name argument to realpath(), NULL is
> specified to cause an [EINVAL] return; I think we are stuck with that
> but should not add more such cases. Note that this [EINVAL] return also
> means that realpath(NULL, p) is valid to do and should not trigger
> undefined behaviour detectors..

I'm not clear where you stand on this. Is EINVAL more proper or EBADF,
or are you against the change all together?

I find this sort of seat belt good for portability and of little harm.

> 
> -- 
> 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/4efb8ba4/attachment.sig>