From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: fnmatch and FNM_CASEFOLD
Date: Sun, 1 Dec 2013 17:06:10 -0500 [thread overview]
Message-ID: <20131201220610.GD24286@brightrain.aerifal.cx> (raw)
In-Reply-To: <20131201140235.GA3383@gauss>
On Sun, Dec 01, 2013 at 03:02:35PM +0100, Felix Janda wrote:
> 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().
That makes sense. However there seem to be gnulib tests checking calls
with FNM_LEADING_DIR even though they don't seem to depend on the
behavior. Would removing FNM_LEADING_DIR from musl's fnmatch.h cause
these tests to fail and cause programs using gnulib to pull in the
(highly inefficient and broken) GNU fnmatch source?
> busybox's tar uses it if available for the -X and -T option for file
> in/exclusion.
Sadly removing FNM_LEADING_DIR from musl's headers would not fix
busybox since busybox just defines it to 0 if it's missing and then
proceeds to use it as if it worked... This is documented in the
comments as being something to fix, but I haven't seen any progress on
fixing it.
> 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.
What do you mean by "expects"? What goes wrong if it's missing?
> recoll will only use FNM_LEADING_DIR if it is available. However its
> documentation says it is always used.
Does lack of FNM_LEADING_DIR impact functionality?
> csync2 and dds2tar use the flag unconditionally.
I would guess these mostly work with it as a no-op (like now), only
failing to support some user-provided patterns. Is this true?
> 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.
While writing this email, I actually looked into how FNM_LEADING_DIR
is supposed to work, and it's a trivial one-line change to make it
work in combination with FNM_PATHNAME, so I think we should just add
that, and document that it's a no-op without FNM_PATHNAME. Can you
tell me if this would cover most real-world usage? At some later point
we might be able to add it for non-FNM_PATHNAME. I have ideas how to
do this but I'd like to combine that with an overhaul to the whole
file I have in mind for post-1.0.
Rich
next prev parent reply other threads:[~2013-12-01 22:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-29 9:59 orc
2013-11-29 17:42 ` Rich Felker
2013-11-29 23:34 ` Rich Felker
2013-11-30 21:16 ` Rich Felker
2013-12-01 14:02 ` Felix Janda
2013-12-01 22:06 ` Rich Felker [this message]
2013-12-02 7:26 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131201220610.GD24286@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).