Mail Archives: djgpp/2006/11/30/03:30:58
Alexei A. Frounze wrote:
> Brian Inglis wrote:
>> fOn Wed, 29 Nov 2006 11:34:38 -0500 in comp.os.msdos.djgpp, DJ
>> Delorie <dj AT delorie DOT com> wrote:
>>
>>>
>>>> This function indicates if STRING matches the PATTERN. ..."
>>>>
>>>> So DJGPP says that "\" doesn't match "\\" while Linux says it does.
>>>>
>>>> Well, I say DJGPP is right as the pattern says there should be two
>>>> backslashes and you only provide one.
>>>
>>> Except that PATTERN is a regex influenced by FNM_NOESCAPE and
>>> FNM_PATHNAME, and STRING isn't. So a pattern of "\\" is a single
>>> escaped backslash, whereas a string of "\" is a single backslash.
>>> They should match.
>>
>> switch ((c = *pattern++))
>> {
>> ...
>> ...
>> ...
>> case '\\':
>> /*+++ pattern already post-incremented to point to next char */
>> if (!(flags & FNM_NOESCAPE) && pattern[1] && strchr("*?[\\",
>> pattern[1]))
>> /*+++ should be:
>> if (!(flags & FNM_NOESCAPE) && strchr("*?[\\", *pattern))
>> *+++ as end of input pattern will match end char in escapes string */
>> {
>> /*+++ end of input pattern might be clearer with ! or == '\0' */
>> if ((c = *pattern++) == 0)
>> {
>> c = '\\';
>> --pattern;
>> }
>> if (c != *string++)
>> return FNM_NOMATCH;
>> break;
>> }
>
> I don't think the above is enough. There's another problem. With the
> above code you'd never see (c = *pattern++) == 0. My bet is that the
> intent was to treat the slash in the last character of pattern as an
> ordinary character. That would explain the {c = '\\'; --pattern;}
> thing along with the fallthrough behavior. But the code is broken in
> this place. Dunno if it was tested against the single unix spec or
> just a little bit to see that it seems to work (in some basic cases).
One more thing to consider, closing bracket as first character in the
list/range inside the bracket expression:
fnmatch("[]]", "]", 0) must return 0, doesn't
fnmatch("[!]]", "]", 0) must return 1, does (by luck)
fnmatch("[!]]", "a", 0) must return 0, doesn't
And one more, which seems to be partially wrong even in that same RH9 linux
distro:
fnmatch("\ab\c","abc",0) must return 0, does in linux, doesn't in DJGPP
fnmatch("\[abc\]","[abc]",0) must return 0, doesn't in both linux and
DJGPP -- the spec doesn't make an exception for the escaped opening bracket,
\[ when describes the escaping option. Dunno, maybe it would be wise not to
escape the bracket, but other characters should be made escapable w/o a
problem.
Alex
P.S. all the details obtained from fnmatch()'s description in The Single
Unix Specification V3 2004 issue 6.
P.P.S. of course there's a ton of what DJGPP's fnmatch() doesn't support,
but the above things are pretty basic and it would be nice to have them
handled properly, unless I overlook some major DOS-related issue for which
it would be desirable to deviate from the spec.
- Raw text -