fnmatch.h bug?

fnmatch.h bug?

[林冠儒]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

When I using the musl-libc "fnmatch" function, I found that the return
value is different from glibc.

For example:

musl-libc:
     i = fnmatch( "a\\.c" , "a\.c" , 0 ); // it will return 0 -> i = 0
glibc:
     i = fnmatch( "a\\.c" , "a\.c" , 0 ); // it will also return 0 -> i = 0

So, we know that "a.\\c" will escape " \ " in pattern and will NOT escape
in string.

But in the case:

musl-libc:
     i = fnmatch( "[[?*\\]" , "\\" , 0 ); // it will return 0 -> i = 0
glibc:
     i = fnmatch( "[[?*\\]" , "\\" , 0 ); // it will return 1 -> i = 1

The return value is DIFFERENT !
I am confuse which library is wrong?
If you have any idea, please response me and send an e-mail to me,
Thank you!

[-- Attachment #2: Type: text/html, Size: 1981 bytes --]

Re: fnmatch.h bug?

[Szabolcs Nagy]

* ????????? <g548462@gmail.com> [2014-08-06 11:01:40 +0800]:
> 
> musl-libc:
>      i = fnmatch( "[[?*\\]" , "\\" , 0 ); // it will return 0 -> i = 0
> glibc:
>      i = fnmatch( "[[?*\\]" , "\\" , 0 ); // it will return 1 -> i = 1
> 
> The return value is DIFFERENT !
> I am confuse which library is wrong?
> If you have any idea, please response me and send an e-mail to me,

in a bracket expression a backslash loses its special meaning
so this pattern matches a single '[', '?', '*' or '\\' character

if glibc fails to match '\\' then it's a bug in their implementation

(this exact pattern is even part of the libc-test suite for fnmatch)

Re: fnmatch.h bug?

[林冠儒]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

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.

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 ?

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



2014-08-06 14:28 GMT+08:00 Szabolcs Nagy <nsz@port70.net>:

> * ????????? <g548462@gmail.com> [2014-08-06 11:01:40 +0800]:
> >
> > musl-libc:
> >      i = fnmatch( "[[?*\\]" , "\\" , 0 ); // it will return 0 -> i = 0
> > glibc:
> >      i = fnmatch( "[[?*\\]" , "\\" , 0 ); // it will return 1 -> i = 1
> >
> > The return value is DIFFERENT !
> > I am confuse which library is wrong?
> > If you have any idea, please response me and send an e-mail to me,
>
> in a bracket expression a backslash loses its special meaning
> so this pattern matches a single '[', '?', '*' or '\\' character
>
> if glibc fails to match '\\' then it's a bug in their implementation
>
> (this exact pattern is even part of the libc-test suite for fnmatch)
>

[-- Attachment #2: Type: text/html, Size: 2780 bytes --]

Re: fnmatch.h bug?

[Rich Felker]

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