Re: questions and maybe a patch about fdopendir in coreutils

[Jim Meyering]

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.