Paul Eggert <[EMAIL PROTECTED]> wrote: > A few things things about fdopendir. > > 1. Yesterday, fdopendir was added to glibc. The patch below attempts > to address this, but I have a few qualms about this since I haven't > tested it with glibc CVS, though -- I don't have that easily > available. > > 2. I'm not sure what that AT_FDCWD test is doing in fdopendir's > implementation. That behavior isn't documented in the Sun manual that
It doesn't belong. Thanks for catching it. > I can see. (It's not in glibc either, but that's to be expected.) As > far as I can see, coreutils never passes AT_FDCWD to fdopendir so > removing this test shouldn't change coreutils itself. > > 3. The Sun documentation says fdopendir consumes its fd only if > fdopendir is successful. Another. Thanks again. > 4. Is all this academic? coreutils never uses lib/openat.c's > fdopendir that I can see. getcwd.c uses fdopendir only if AT_FDCWD is > defined in the system headers, which means it doesn't use openat.c's > fdopendir, right? It's not academic at all. I added that function because an upcoming, sometimes-thread-safe, version of remove.c requires it. > Maybe fdopendir should simply be removed from openat.h and openat.c, > to avoid possible collisions with glibc? > > But if not, here's a proposed patch: Thanks. Applied. > 2005-09-29 Paul Eggert <[EMAIL PROTECTED]> > > * lib/openat.c (fdopendir): Do not define if HAVE_FDOPENDIR. > Remove AT_FDCWD test. > Do not consume the fd unless successful. > * lib/openat.h (fdopendir): Do not define if HAVE_FDOPENDIR. > * m4/openat.m4 (gl_FUNC_OPENAT): Check for fdopendir. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
