[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230109073213.GB4163@brightrain.aerifal.cx>
Date: Mon, 9 Jan 2023 02:32:13 -0500
From: Rich Felker <dalias@...c.org>
To: "(GalaxyMaster)" <galaxy@...nwall.com.au>
Cc: musl@...ts.openwall.com
Subject: Re: is fnmatch() a bit broken?
On Sun, Jan 08, 2023 at 01:45:09PM +0000, (GalaxyMaster) wrote:
> Hello,
>
> I haven't analysed the fnmatch.c in musl yet, but I wrote a quick test to
> demonstrate the issue:
> ===
> #include <fnmatch.h>
> #include <stdio.h>
>
> #define TEST_FNMATCH(pattern, haystack, expect) \
> ({ \
> printf("fnmatch(\"%s\", \"%s\", 0) = %d (expected: %d)\n", \
> pattern, haystack, \
> fnmatch(pattern, haystack, 0), expect); \
> })
>
> int main()
> {
> TEST_FNMATCH("abc", "abc", 0);
> TEST_FNMATCH("[1\\]] [1\\]]", "1 ]", 0);
> TEST_FNMATCH("[a-c-f] [a-c-f] [a-c-f] [a-c-f] [a-c-f]", "a b c - f", 0);
> TEST_FNMATCH("[a-c-f]", "e", 1);
> TEST_FNMATCH("[a\\-z]", "b", 1);
> return 0;
> }
> ===
>
> Below is a session on a box with musl 1.2.3:
> ===
> galaxy@...llo:~/musl-fnmatch $ gcc -o musl-fnmatch musl-fnmatch.c
> galaxy@...llo:~/musl-fnmatch $ ./musl-fnmatch
> fnmatch("abc", "abc", 0) = 0 (expected: 0)
> fnmatch("[1\]] [1\]]", "1 ]", 0) = 1 (expected: 0)
> fnmatch("[a-c-f] [a-c-f] [a-c-f] [a-c-f] [a-c-f]", "a b c - f", 0) = 1 (expected: 0)
> fnmatch("[a-c-f]", "e", 0) = 0 (expected: 1)
> fnmatch("[a\-z]", "b", 0) = 0 (expected: 1)
> galaxy@...llo:~/musl-fnmatch $ ldd ./musl-fnmatch
> /lib/ld-musl-x86_64.so.1 (0x7f25af652000)
> libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f25af652000)
> galaxy@...llo:~/musl-fnmatch $ rpm -q musl
> musl-1.2.3-owl0.x86_64
> galaxy@...llo:~/musl-fnmatch $
> ===
>
> As you may see from above the patterns are not that crazy (they were actually
> taken from the systemd test case, since I am trying to build the latest systemd
> with musl correctly, but this is offtopic). The most concerning are the last
> three patterns, since obviously musl's fnmatch() seems to be greedy and also
> does not respect escape character in some cases, e.g. in "[a\-z]" it is common
> sense to treat it as 'a', '-', or 'z'.
This difference is intentional because glibc's behavior is contrary to
the spec. Glob/fnmatch brackets are equivalent to (specified as) regex
brackets where the only way to include a literal - is at the
beginning/end. A '\' can escape the '[' and make it non-special (not
open a bracket) but the '-' inside the bracket is not "special" to
begin with -- it's just part of the bracket syntax. Likewise with the
closing ']' case.
Regarding the [a-c-f] case, POSIX specifies:
"The interpretation of range expressions where the ending range point
is also the starting range point of a subsequent range expression (for
example, "[a-m-o]" ) is undefined."
so this test is explicitly invalid.
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.
