Re: [patch v2] glob: resolve DT_UNKNOWN via is_dir

[DJ Delorie]

Paul Eggert <eggert@cs.ucla.edu> writes:
> I don't see how the patch fixes the case where readdir_result_type (d) 
> returns DT_LNK; this might be a symlink to a directory.

It was not part of the problem I was trying to solve.  A DT_LNK was
already a known file type, and handled, so I left it alone.

> Proposed pair of patches attached (I haven't installed these). The first 
> is yours but with tabs turned to spaces and with ChangeLog equal to your 
> log entry. The second contains my proposed improvements. I haven't 
> tested except on the Gnulib test cases (which aren't much).

I tested it on upstream glibc; it needs one #undef but was otherwise ok.

Reviewed-by: DJ Delorie <dj@redhat.com>

> Of course performance will suffer with all these correctness patches, 
> but that can wait until a rewrite.

Modern XFS and EXT filesystems should not hit these code paths at all,
except for symbolic links, and even then only with GLOB_ONLYDIR.

> +# define dirfd(str) __dirfd (str)

This needs an #undef before it, else it causes build errors as glibc
already has a definition for dirfd() and it conflicts with this one.
Prudence says they should *all* be protected as such, but I only mention
the new one.

> +                  case DT_LNK: case DT_UNKNOWN:

I contemplated the case of symbolic links; I couldn't find anything in
the standards about it but I went with "glob does what shell wildcards
do" and those followed links, and I think that makes sense, so OK.  I
added that case to my local test area and it seems to do what I think
people will expect it to do.