Re: fnmatch and FNM_CASEFOLD

[Rich Felker <dalias@aerifal.cx>]

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