Re: [PATCH 1/6] Add string comparison functions that respect the ignore_case variable.

On Mon, Aug 30, 2010 at 14:42, Joshua Jensen [off-list ref] wrote:

 ----- Original Message -----
From: Ævar Arnfjörð Bjarmason
Date: 8/29/2010 1:39 PM

quoted

On Wed, Aug 18, 2010 at 18:32, Johannes Sixt[off-list ref]  wrote:

quoted

On Mittwoch, 18. August 2010, Ævar Arnfjörð Bjarmason wrote:

quoted

According to some further research at least FreeBSD and NetBSD have
copied this GNU extension. You may find their versions easier to
integrate.

We already have a GNU fnmatch in compat/fnmatch.

Do you have any plan to deal with this? I currently have this
monkeypatch to build on Solaris:

    diff --git a/Makefile b/Makefile
    index 62d526a..079fae5 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -863,2 +863,4 @@ endif
     ifeq ($(uname_S),SunOS)
    +       COMPAT_OBJS = compat/fnmatch/fnmatch.o
    +       COMPAT_CFLAGS = -Icompat -Icompat/fnmatch
            NEEDS_SOCKET = YesPlease

One way to deal with it would be a new NONGNU_FNMATCH=UnfortunatelyYes
flag, or the fnmatch_icase() suggestion above which we could bundle
and always use. But having next build on systems without GNU
extensions would be preferrable.

I am going to deal with this, but I haven't been around.  I hope for some
time this week.

Sure, no rush. I was just wondering whether you had some plan for it,
or whether I should submit a patch to use the fallback on
e.g. Solaris.

Short of duplicating fnmatch's code and renaming the function, I am not sure
how to make this play nice on all systems.

I don't think duplicating the GNU (or *BSD) version into a
compat/fnmatch.c would be a bad thing. See e.g. compat/snprintf.c.

You added COMPAT_OBJS above, but I think there is no linker
guarantee it will pick up compat/fnmatch/fnmatch.o over the C
runtime version?  Perhaps the makefile is architected to do so.

It's probably just an artifact of how the Solaris linker works, it
doesn't go through the trouble of undefining an existing fnmatch
symbol or anything.

The safest alternative is to allocate character buffers, lowercase the
filename and match arguments into those buffers, and pass them off to
fnmatch without any special flags.  I don't like the idea of a double memory
allocation/free combo per each call to this function, but it would work.  Is
anyone opposed to this approach?

Just using the GNU extension and providing a fallback is probably
cleaner and easier to maintain.