mailing list of musl libc
 help / color / mirror / code / Atom feed
* fnmatch test question
@ 2014-10-14 19:02 Justin Cormack
  2014-10-14 19:58 ` Szabolcs Nagy
  0 siblings, 1 reply; 2+ messages in thread
From: Justin Cormack @ 2014-10-14 19:02 UTC (permalink / raw)
  To: musl

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
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03_05

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
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_01
says

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?

Justin


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: fnmatch test question
  2014-10-14 19:02 fnmatch test question Justin Cormack
@ 2014-10-14 19:58 ` Szabolcs Nagy
  0 siblings, 0 replies; 2+ messages in thread
From: Szabolcs Nagy @ 2014-10-14 19:58 UTC (permalink / raw)
  To: musl

* Justin Cormack <justin@specialbusservice.com> [2014-10-14 20:02:18 +0100]:
> 
> 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.
> 

yes these tests follow the re bracket spec

> However, this is for an RE bracket expression which is not exactly the
> same as an fnmatch one and the fnmatch definition
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_01
> says
> 
> 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

i read it as

"when pattern matching is used [...] in the pattern argument
to the fnmatch function, special characters can be escaped"

so fnmatch bracket is not like re bracket..

this is news to me

> 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.

i wonder how the shell is supposed to use the fnmatch api..

> 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?

i think musl is not correct, but the requirement about what
can be escaped where could be clearer

> 
> Justin


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-10-14 19:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-14 19:02 fnmatch test question Justin Cormack
2014-10-14 19:58 ` Szabolcs Nagy

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).