Alain Guibert <[EMAIL PROTECTED]> writes:
>> Maybe you could put a breakpoint in fnmatch and see what goes wrong?
>
> The for loop intended to eat several characters from the string also
> advances the pattern pointer. This one reaches the end of the pattern,
> and points to a NUL. It is not a '*' anymore, so the loop exits
> prematurely. Just below, a test for NUL returns 0.
Thanks for the analysis. Looking at the current fnmatch code in
gnulib, it seems that the fix is to change that NUL test to something
like:
if (c == '\0')
{
/* The wildcard(s) is/are the last element of the pattern.
If the name is a file name and contains another slash
this means it cannot match. */
int result = (flags & FNM_PATHNAME) == 0 ? 0 : FNM_NOMATCH;
if (flags & FNM_PATHNAME)
{
if (!strchr (n, '/'))
result = 0;
}
return result;
}
But I'm not at all sure that it covers all the needed cases. Maybe we
should simply switch to gnulib-provided fnmatch? Unfortunately that
one is quite complex and quite hard for the '**' extension Micah
envisions. There might be other fnmatch implementations out there in
GNU which are debugged but still simpler than the gnulib/glibc one.
It's kind of ironic that while the various system fnmatches were
considered broken, the one Wget was using (for many years
unconditionally!) was also broken.
