Re: [PATCH 3/3] verify_path: consider dos drive prefix

> On Tue, Jun 7, 2011 at 5:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Erik Faye-Lund <kusmabite@gmail.com> writes:
>>
>>>> Nitpick: If you already know that c != '\0' and !is_dir_sep(c), then why do
>>>> continue? It will check for '\0' and is_dir_sep(c) again, but you already
>>>> know that both ifs will be false. So you could just as easy jump straight to
>>>> c = *path++, which IMHO also makes the code easier to follow:
>>>
>>> Very good point, thanks for noticing. I just rewrote the logic from
>>> switch/case to if/else, but with the rewrite these redundant compares
>>> became more obvious. I think your version is better, indeed.
>>
>> Let's not add an unnecessary goto while at it.  How about this on top
>> instead?
>>
>>  read-cache.c |   13 +++----------
>>  1 files changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/read-cache.c b/read-cache.c
>> index 31cf0b5..3593291 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -784,16 +784,9 @@ int verify_path(const char *path)
>>                if (is_dir_sep(c)) {
>>  inside:
>>                        c = *path++;
>> -                       switch (c) {
>> -                       default:
>> -                               continue;
>> -                       case '/': case '\0':
>> -                               break;
>> -                       case '.':
>> -                               if (verify_dotfile(path))
>> -                                       continue;
>> -                       }
>> -                       return 0;
>> +                       if ((c == '.' && !verify_dotfile(path)) ||
>> +                           is_dir_sep(c) || c == '\0')
>> +                               return 0;
>>                }
>>                c = *path++;
>>        }
>
> This change the "c == '.' && verify_dotfile(path)"-case to eat the '.'
> character without testing it against is_dir_sep, which is exactly what
> we want. The other cases return 0, as they used to. Good.
>
> Indeed, this is a cleaner approach. Thanks!
>