Re: [PATCH 4/8] wildmatch: support "no FNM_PATHNAME" mode

[Nguyen Thai Ngoc Duy <pclouds@gmail.com>]

On Fri, Dec 28, 2012 at 1:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>                       if (*++p == '*') {
>>                               const uchar *prev_p = p - 2;
>>                               while (*++p == '*') {}
>> -                             if ((prev_p == text || *prev_p == '/') ||
>> +                             if (!(flags & WM_PATHNAME))
>> +                                     /* without WM_PATHNAME, '*' == '**' */
>> +                                     special = 1;
>> +                             else if ((prev_p == text || *prev_p == '/') ||
>
> Not a new issue in this patch,

No, it's an issue from nd/wildmatch, 40bbee0 (wildmatch: adjust "**"
behavior - 2012-10-15).

> but here, "prev_p" points into the
> pattern string, two bytes before p, which is the byte before the
> "**" that we are looking at (which might be before the beginning of
> the pattern).  "text" is the string we are trying to match that
> pattern against.  How can these two pointers be compared to yield a
> meaningful value?

They can't. I wanted to check whether "**" is at the start of the
pattern (so no preceding '/' needed) and used a wrong pointer to
compare to. Funny there is a test about this and it does not catch it
because prev_p access something before the pattern. Will fix.

>
>>                                   (*p == '\0' || *p == '/' ||
>>                                    (p[0] == '\\' && p[1] == '/'))) {
>
> OK.  "**/", "**" (end of pattern), and "**\/" are handled here.
>
> Do we have to worry about "**[/]" the same way, or a class never
> matches the directory separator, even if it is a singleton class
> that consists of '/' (which is fine by me)?  If so, is "\/" more or
> less like "[/]"?

This is a special case of "**" with FNM_PATHNAME on. With
FNM_PATHNAME, '[]' and '?' cannot match '/' so any patterns with '[/]'
match nothing. I think we don't need to worry about this case.
-- 
Duy