Re: fnmatch bug?

Re: fnmatch bug?

[Szabolcs Nagy]

* ????????? <g548462@gmail.com> [2014-08-06 18:11:22 +0800]:
> I have do another experiment.
> 

i added the mailing list back to CC in case others have fnmatch
issues as well

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

fnmatch behaviour is unclear when the pattern ends in \
this is a bug in posix 2008 we reported earlier:

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

in the next revision of posix the current behaviour will
be non-conforming (there is a test for this in libc-test)

with FNM_NOESCAPE \ is not special so '\\' matches '\\'

> 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

yes this is allowed

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

glibc is wrong here, in a bracket expression \ is not special
in any way, "[1\\]" only matches a single '1' or '\\' character