X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
NNTP-Posting-Date: Thu, 30 Nov 2006 02:21:06 -0600
From: "Alexei A. Frounze" <alexfru AT chat DOT ru>
Newsgroups: comp.os.msdos.djgpp
References: <iKydndAovO98z_DYnZ2dnUVZ_sadnZ2d AT comcast DOT com> <LO6dnbePOLnKzvDYnZ2dnUVZ_sGdnZ2d AT comcast DOT com> <456dad03$0$486$cc7c7865 AT news DOT luth DOT se> <200611291634 DOT kATGYcbw010800 AT envy DOT delorie DOT com> <n6qsm2l2pk3svjtu7aqu68mmhdmvldprk5 AT 4ax DOT com> <Sb6dnSX2_Plh5_PYnZ2dnUVZ_rSdnZ2d AT comcast DOT com>
Subject: Re: fnmatch("\\\\", "\\", 0) == 1 ???
Date: Thu, 30 Nov 2006 00:20:00 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Message-ID: <IZWdndsG8_TvCfPYnZ2dnUVZ_rGdnZ2d@comcast.com>
Lines: 73
NNTP-Posting-Host: 24.18.54.10
X-Trace: sv3-d7UhuDkJT+kCA799P4F5B8d7M8dv28kqNbFPXBa53f0C4WD3WyLM87jHGCOV9FTUq7Wj704l+cfUKyI!FgTE4beBz1fyk5iqO5l3kW1Xp87JExPqBTHe2u41kBUNXXPR9z1LSQYbU+h54Ppc3sj9LSwyRU2C!ijTJcKJ2nQ==
X-Complaints-To: abuse AT comcast DOT net
X-DMCA-Complaints-To: dmca AT comcast DOT net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.32
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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.