From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15839 invoked from network); 9 Jan 2023 07:32:30 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 9 Jan 2023 07:32:30 -0000 Received: (qmail 32171 invoked by uid 550); 9 Jan 2023 07:32:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32130 invoked from network); 9 Jan 2023 07:32:26 -0000 Date: Mon, 9 Jan 2023 02:32:13 -0500 From: Rich Felker To: "(GalaxyMaster)" Cc: musl@lists.openwall.com Message-ID: <20230109073213.GB4163@brightrain.aerifal.cx> References: <0100018591a0bfbc-4edc55e0-b5eb-42ef-9d8e-12d9f0d09afd-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0100018591a0bfbc-4edc55e0-b5eb-42ef-9d8e-12d9f0d09afd-000000@email.amazonses.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 > #include > > #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@apollo:~/musl-fnmatch $ gcc -o musl-fnmatch musl-fnmatch.c > galaxy@apollo:~/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@apollo:~/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@apollo:~/musl-fnmatch $ rpm -q musl > musl-1.2.3-owl0.x86_64 > galaxy@apollo:~/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