From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4321 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: fnmatch and FNM_CASEFOLD Date: Sun, 1 Dec 2013 17:06:10 -0500 Message-ID: <20131201220610.GD24286@brightrain.aerifal.cx> References: <20131129174249.GC24286@brightrain.aerifal.cx> <20131129233417.GK24286@brightrain.aerifal.cx> <20131130211612.GX24286@brightrain.aerifal.cx> <20131201140235.GA3383@gauss> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1385935581 15262 80.91.229.3 (1 Dec 2013 22:06:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Dec 2013 22:06:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4325-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 01 23:06:28 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VnF9m-0003tk-0s for gllmg-musl@plane.gmane.org; Sun, 01 Dec 2013 23:06:26 +0100 Original-Received: (qmail 12041 invoked by uid 550); 1 Dec 2013 22:06:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 12032 invoked from network); 1 Dec 2013 22:06:23 -0000 Content-Disposition: inline In-Reply-To: <20131201140235.GA3383@gauss> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4321 Archived-At: 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