Re: fnmatch.h bug?

[Rich Felker <dalias@libc.org>]

On Wed, Aug 06, 2014 at 06:03:33PM +0800, 林冠儒 wrote:
> I have do another experiment.
> 
> musl-libc:
>      i = fnmatch("\\","\\",0);  // it returns 0 -> i=0
>      i = fnmatch("\\","\\",FNM_NOESCAPE);  // it also returns 0 -> i=0
> 
> But I think this two lines of code should return different value because I
> set the FNM_NOESCAPE flag.

Per a strict reading of the current text of backslash is not special
when it appears at the end of the pattern string. See Austin Group
issue #806:

http://austingroupbugs.net/view.php?id=806

However, the way this was resolved (treating the final backslash as
unmatchable or as an error) does not match musl's current behavior, so
musl should be changed here.

> I also do same experiment in glibc:
> glibc:
>      i = fnmatch("\\","\\",0);  // it returns 1 -> i=1
>      i = fnmatch("\\","\\",FNM_NOESCAPE);  // it  returns 0 -> i=0
> 
> 
> In another case:
> musl-libc:
>      i = fnmatch("[1\\]","[1]",0);  // it returns 1 -> i=1
> glibc:
>      i = fnmatch("[1\\]","[1]",0);  //it returns 0 -> i=0
> 
> Because I DON'T set FNM_NOESCAPE flag, so glibc will escape ']' with two '\'
> And the return value should be 0 (match '[1]')
> Is it right ?

As nsz said, my interpretation of the requirements is that backslash
in a bracket expression is never special; it is an ordinary character.
This has been discussed before and nobody was able to prevent
convincing evidence to the contrary, but it's been a while since I
looked into the issue and I don't have the references handy.

> It would be very helpful if you email me back and tell me what's the problem
> Sorry ,my english is so poor.

No problem, you're communicating fine.

Rich