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
