Paul, Eli, and Eric: thanks for looking into this and providing information about the problem.
On Thu, Mar 19, 2015 at 12:18 PM, Paul Eggert <egg...@cs.ucla.edu> wrote: > On 03/19/2015 09:19 AM, Eli Zaretskii wrote: >> I suggest the following simpler >> change instead: > Thanks, I installed that, with a briefer code comment. I have not tested Eli's simpler change, but I expect it would fix the bug in grep, and the bug in by test program at the beginning of this thread. However, two things about that patch seem wrong to me: 1) In the specification of fdeopdir, POSIX requires that closedir(fdopendir(fd)) will close fd, assuming fdopendir was successful. That patch does nothing to associate the duplicated file descriptor to the DIR pointer, so the file descriptor will not be closed by closerdir. This is not POSIX compliant, and I think this would lead to memory leaks in applications that use fdopendir and closedir. Also, if the file descriptor has any OS-level connection to a directory, it might cause bad side effects in Windows, like making the directory undeletable or unmovable by other applications. In this way, that patch is not so different from my original bad workaround, which was to comment out the "close (fd);" line in fdopendir, except my workaround probably leaked memory faster. 2) It seems odd to me that inside fdopendir, Gnulib would close the file descriptor, then follow this complicated, non-thread-safe recursive strategy, and then at the end it would essentially realize that the whole thing was a waste of time, and just dup the file descriptor to recover. I thought the whole point of the close/dup/recursive thing was to trick the base system into using the right file descriptor for the new DIR pointer, so that it would get closed later by closedir. Since that isn't the case in MinGW, don't need the close/dup/recursive thing. It seems like Gnulib should know at compile time what type of system it is running on, and try to use that to avoid doing extra work. >From the small bits of the POSIX API that I have read (dirfd, fdopendir, closedir), it really seems like it is suited for an implementation where every DIR pointer (or at least the DIR pointers created by fdopendir) must be associated with a file descriptor. So it would be great to get that association working. I will look at the older discussion about dirfd mentioned by Paul, and the implementations of open and fchdir, and probably try to come up with a patch some time. --David
