-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hrvoje Niksic wrote:
> 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.
I'm thinking not: the loop still shouldn't be incrementing n, since that
forces each additional * to match at least one character, doesn't it?
Gnulib's version seems to handle that better.
> 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.
Maybe. I'm not sure ** would be too hard to add to gnulib's fnmatch,
just have to toggle with the FNM_FILE_NAME tests within the '*' case, if
we see an immediate second '*'. But maybe ** as part of a *?**? sequence
is more complex. I don't think so, though.
The main thing is that we need it to support the invalid sequence stuff.
Hm; I'm not sure we'll ever want fnmatch() to be locale-aware, though.
User-specified match patterns should interpret characters based on the
locale; but the source strings may be in different encodings altogether.
If we solve this by transcoding to the current locale, we may find that
the user's locale doesn't support all of the characters that the
original string's encoding does. Probably we'll need to transcode both
to Unicode before comparison.
In the meantime, though, I think we want a simple byte-by-byte match.
Perhaps it's best to (a) use our custom matcher, ignoring the system's
(so we don't get locale specialness), and (b) fix it, providing as
thorough test coverage as possible.
- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer,
and GNU Wget Project Maintainer.
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH9jWi7M8hyUobTrERAglwAKCDnpnDjr44Ovgh/oBuzkM4mu/gKACeNnN8
arvFSrCEBatNeO29fzHxuU4=
=QDMp
-----END PGP SIGNATURE-----
