>> So they are otherwise 100% expression compatible?
>
> As for the test-cases, I am observing some minor diferences on my box,
> mostly
> in handling of some corner cases:

Yes, there probably are some differences.

> +fnmatch("[", "[") should return 2 (returns 1)
> +fnmatch("[]", "[]") should return 2 (returns 1)
> +fnmatch("\", "\") should return 2 (returns 1)
I've added ERROR case (return 2) to report bad syntax without errno.

> +fnmatch("[a-z]", "A") should return 1 (returns 0)
> +fnmatch("[A-Z]", "c") should return 1 (returns 0)
If I'm not wrong, fnmatch should be case sensitive..!

> +fnmatch("*.txt", ".txt") should return 0 (returns 1)
> +fnmatch("****.txt", ".txt") should return 0 (returns 1)
And that is really weird...

> We can tweak it to match with the other implementation.

> I also suggest to enable valgrind as it reports no error anyway!
Ok. Even if there are no alloc's, there could be other problems. I'll turn
it on.

There is a little problem, that all fnmatch(3) implementations has
different
behavior. Some does not have '[[:alhpa:]]' notation, some are using
wchar_t,
I have seen '[.c.]' or '[=c=]' notation too. I think it is the reason why
to implement it into curl and apps can count with consistent behavior.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-04-26