[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: questions and maybe a patch about fdopendir in coreutils
From: |
Jim Meyering |
Subject: |
Re: questions and maybe a patch about fdopendir in coreutils |
Date: |
Fri, 30 Sep 2005 16:13:39 +0200 |
Paul Eggert <address@hidden> 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 <address@hidden>
>
> * 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.