This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

bug in fdopendir


I'm looking at Corinna's new fdopendir implementation:

http://cygwin.com/ml/cygwin-cvs/2007-q2/msg00064.html

First, thanks for doing it.  Second, I think there may be a couple of bugs.

The fd handed to fdopendir must be consumed by the DIR, therefore the
closedir must close it.  POSIX (well, the draft POSIX 200x) states that
behavior is undefined if a user calls close(fd) after calling
fdopendir(fd); it also states that calling closedir() must close the fd
originally passed in to fdopendir (if the implementation of DIR tracks an
underlying fd, which it does in cygwin).  Your special treatment of
whether the DIR wraps an internal fd created by opendir, or whether it was
an external fd handed through fdopendir, ends up being a leak of file
descriptors in closedir in dir.cc when a compliant program uses fdopendir
properly.

Also, POSIX is clear that DIR streams are not inherited across processes.
 I'm not quite sure why you are using OBJ_INHERIT in fhandler_disk_file.cc
in the case of opendir, but that code did not change from before your
patch.  I also wonder if you need to tweak the fdopendir code to insure
that if the directory fd was previously inheritable, that the fdopendir
changes it to FD_CLOEXEC.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]