[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131201140235.GA3383@gauss>
Date: Sun, 1 Dec 2013 15:02:35 +0100
From: Felix Janda <felix.janda@...teo.de>
To: musl@...ts.openwall.com
Subject: Re: fnmatch and FNM_CASEFOLD
Rich Felker wrote:
> On Fri, Nov 29, 2013 at 06:34:17PM -0500, Rich Felker wrote:
[...]
> > 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
The vast majority of the matches comes from code copied from gnulib,...
implementing fnmatch().
busybox's tar uses it if available for the -X and -T option for file
in/exclusion.
Jane Street's core library for OCaml provides libc's version of
fnmatch() to its users. Its implementation expects FNM_LEADING_DIR
(and also FNM_CASE_FOLD) to exists.
recoll will only use FNM_LEADING_DIR if it is available. However its
documentation says it is always used.
csync2 and dds2tar use the flag unconditionally.
sitecopy checks in its config script for the existance of FNM_LEADING_DIR
and uses it if declared. It is therefore currently broken for musl and
fixed if one removes the declaration.
Felix
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
