bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnulib] Re: [patch] findutils-4.1.20: use d_type in struct dirent


From: Jakub Jelinek
Subject: [Bug-gnulib] Re: [patch] findutils-4.1.20: use d_type in struct dirent
Date: Tue, 30 Mar 2004 15:22:08 +0200
User-agent: Mutt/1.4i

Hi!

Bruno Haible wrote:

> Although using d_type instead of lstat() evidently increases performance,
> I'd prefer to see a patch which
>
> - Uses the same interface on all platforms: Use DT_UNKNOWN instead of
>   d_type on those platforms that don't have d_type. (Interfaces that
>   depend on the platform easily lead to bugs that appear only on some
>   platforms and not on others, defeating the purpose of gnulib.)

When I wrote the patch initially (findutils-4.1.7), I didn't know savedir
was used by anything but findutils.  When it is used by more than one
project, it of course needs to have the same interface everywhere.

There are IMHO two options, either provide the d_type bytes unconditionally,
or add a new argument to savedir and let the caller choose whether it wants
them or not.  I think the former is better and is implemented in the
attached updated patch against findutils-4.1.20.

> - Uses a more appropriate data structure than a NUL terminated
>   string whose last byte is a d_type value. (Btw, you know that on
>   Linux, DT_UNKNOWN is 0; therefore when running on a newer libc but
>   with an older kernel, readdir() will return d_type = DT_UNKNOWN for
>   all entries, and you get fooled into cutting off the last byte of
>   the real filename and interpreting it as a d_type value!)

That's not what the patch uses.  savedir returns:
filename1 '\0' d_type1 filename2 '\0' d_type2 '\0'
d_typeN is one byte, it doesn't matter at all whether it is 0 or non-zero
for parsing what is a filename, what is d_type and where the list
ends (termination is done by filename with zero length).

Jim Meyering wrote:

> It looks like a good idea, though I have to confess that coreutils is
> moving away from savedir -- and from explicit recursion for file system
> traversals.  Although there still remains one use of savedir (in copy.c),
> that will be removed when copy.c is rewritten to use lib/fts.c.

Unfortunately, neither fts nor *ftw* can save the {,l}stat{,64}'s done
by find.  *ftw* provides struct stat{,64} unconditionally, fts has
FTS_NOSTAT, but then no mode is provided at all.

        Jakub

Attachment: findutils-4.1.20-d_type.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]