From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4322 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: fnmatch and FNM_CASEFOLD Date: Mon, 2 Dec 2013 02:26:30 -0500 Message-ID: <20131202072630.GF24286@brightrain.aerifal.cx> References: <20131129174249.GC24286@brightrain.aerifal.cx> <20131129233417.GK24286@brightrain.aerifal.cx> <20131130211612.GX24286@brightrain.aerifal.cx> <20131201140235.GA3383@gauss> <20131201220610.GD24286@brightrain.aerifal.cx> 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 1385969199 2784 80.91.229.3 (2 Dec 2013 07:26:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Dec 2013 07:26:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4326-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 02 08:26:45 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 1VnNu0-0000EN-RN for gllmg-musl@plane.gmane.org; Mon, 02 Dec 2013 08:26:44 +0100 Original-Received: (qmail 22367 invoked by uid 550); 2 Dec 2013 07:26:43 -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 22359 invoked from network); 2 Dec 2013 07:26:42 -0000 Content-Disposition: inline In-Reply-To: <20131201220610.GD24286@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4322 Archived-At: On Sun, Dec 01, 2013 at 05:06:10PM -0500, Rich Felker wrote: > 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. I found a trivial but inefficient way to handle the non-FNM_PATHNAME case too, so I've implemented both and committed. Now FNM_LEADING_DIR should be fully supported/working. FNM_CASEFOLD on the other hand remains a no-op and I'm unclear on what to do with it. The intent of POSIX seems to be that fnmatch bracket expressions behave like RE brackets, for which POSIX specifies case-insensitive semanics (for REG_ICASE flag, etc.) that disagree with what glibc is doing. So the choices we're stuck with are implementing a "correct" version of a nonstandard interface that differs from the real-world systems it's modeled after, an "incorrect" case-insensitivity, or something else entirely. It's messy enough that I see why I originally did not even want to go here at all, but I'm not sure what we should do. Rich