Re: [patch] glob: resolve DT_UNKNOWN via is_dir

2021-11-17 Thread DJ Delorie
Florian Weimer writes: > I thought the bug is that it's not actually a hint? That DT_UNKNOWN > here leads to incorrect results in glob? All the DT_* are hints, according to the man pages, which say that DT_UNKNOWN must be handled by the caller. So I guess it depends on whether the original

Re: [patch] glob: resolve DT_UNKNOWN via is_dir

2021-11-17 Thread Florian Weimer
* DJ Delorie: > Florian Weimer writes: >>> + if (fullpath == NULL) >>> + /* This matches old behavior wrt DT_UNKNOWN. */ >>> + break; >> >> Shouldn't this report memory allocation failure to the caller? > > We could easily replace that break

Re: [patch] glob: resolve DT_UNKNOWN via is_dir

2021-11-17 Thread DJ Delorie
Florian Weimer writes: >> + if (fullpath == NULL) >> +/* This matches old behavior wrt DT_UNKNOWN. */ >> +break; > > Shouldn't this report memory allocation failure to the caller? We could easily replace that break with a "goto

Re: [patch] glob: resolve DT_UNKNOWN via is_dir

2021-11-17 Thread Florian Weimer
* DJ Delorie: > diff --git a/lib/glob.c b/lib/glob.c > index 22c459574..d0521bb4a 100644 > --- a/lib/glob.c > +++ b/lib/glob.c > @@ -1381,7 +1381,26 @@ glob_in_dir (const char *pattern, const char > *directory, int flags, >if (flags & GLOB_ONLYDIR) > switch

[patch] glob: resolve DT_UNKNOWN via is_dir

2021-11-16 Thread DJ Delorie
The DT_* values returned by getdents (readdir) are only hints and not required. In fact, some Linux filesystems return DT_UNKNOWN for most entries, regardless of actual type. This causes make to mis-match patterns with a trailing slash (via GLOB_ONLYDIR) (see make's functions/wildcard test