Re: fnmatch and FNM_CASEFOLD

[Rich Felker <dalias@aerifal.cx>]

On Fri, Nov 29, 2013 at 06:34:17PM -0500, Rich Felker wrote:
> On Fri, Nov 29, 2013 at 12:42:49PM -0500, Rich Felker wrote:
> > On Fri, Nov 29, 2013 at 05:59:12PM +0800, orc wrote:
> > > Hi list,
> > > 
> > > This one really terrorized me well. Musl defines FNM_CASEFOLD in
> > > fnmatch.h but really does nothing when this flag is passed to
> > > function. This breaks busybox find -iname I believe, instead of file
> > > list matching "Test" among with "test" i get only those which
> > > contain "test" in their names with -iname "test". Missed lot of
> > > files because of it.
> > > Wishing this fixed or such define being removed.
> > 
> > I think this is a reasonable request. FNM_CASEFOLD is problematic to
> 
> I'd also like to remove FNM_LEADING_DIR, which is unsupported by musl
> and documented in the man page as:
> 
>     "This flag is mainly for the internal use of glibc and is
>     implemented only in certain cases."

Unfortunately, Debian codesearch is showing a lot of hits for
FNM_LEADING_DIR; I haven't researched whether they're hard or soft
dependencies, so if anyone is willing to look into that, it'd be
helpful. See: http://codesearch.debian.net/search?q=FNM_LEADING_DIR

I'm not opposed to implementing it if it's non-intrusive. Same goes
for FNM_CASEFOLD though we need to consider what semantics it should
have; nsz has researched what the BSD version does and it's fairly
simple but possibly counter-intuitive or possibly "right" depending on
your perspective. :-)

Unfortunately I'm leaning towards punting on all of these issues until
after 1.0, since it's not clear how much build breakage would result
from (temporarily) removing the macros, whereas the functional
breakage from them being no-ops seems low..

Rich