Date: Mon, 2 Dec 2013 02:26:30 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: fnmatch and FNM_CASEFOLD 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
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.