Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Oct 2014 20:02:18 +0100
From: Justin Cormack <>
Subject: fnmatch test question

I have just started going through the libc-tests repo testing NetBSD
against the test suite and have found some bugs.

However I am somewhat unclear about these two fnmatch tests (which
probably come from dietlibc):

fnmatch("[[?*\\]", "\\", 0) == 0;
fnmatch("[]?*\\]", "]", 0) == 0;

These do not pass on glibc, FreeBSD or NetBSD, they seem to rely on a
view that \ should not be special inside a bracket expression.

Now the bracket expression spec says

The special characters '.', '*', '[', and '\' (period, asterisk,
left-bracket, and backslash, respectively) shall lose their special
meaning within a bracket expression.

However, this is for an RE bracket expression which is not exactly the
same as an fnmatch one and the fnmatch definition

When pattern matching is used where shell quote removal is not
performed (such as in the argument to the find - name primary when
find is being called using one of the exec functions as defined in the
System Interfaces volume of IEEE Std 1003.1-2001, or in the pattern
argument to the fnmatch() function), special characters can be escaped
to remove their special meaning by preceding them with a backslash
character. This escaping backslash is discarded. The sequence "\\"
represents one literal backslash. All of the requirements and effects
of quoting on ordinary, shell special, and special pattern characters
shall apply to escaping in this context.

Which is perhaps contradictory, or maybe just unclear. I tend to think
that Musl is correct form this spec, but not that convinced that I can
currently persuade anyone to change what appears to be standard
practise - any advice?


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.