public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Eric Sunshine <sunshine@sunshineco•com>
Cc: Karthik Nayak <karthik.188@gmail•com>, Git List <git@vger•kernel.org>
Subject: Re: [PATCH v4 05/12] ref-filter: introduce parsing functions for each valid atom
Date: Wed, 03 Feb 2016 17:17:40 -0800	[thread overview]
Message-ID: <xmqqa8nhjmtn.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAPig+cRmfNjP8PYoQFZ7YrECgt03aE1=QynG58-+cd9ORJneZw@mail.gmail.com> (Eric Sunshine's message of "Wed, 3 Feb 2016 17:19:41 -0500")

Eric Sunshine <sunshine@sunshineco•com> writes:

>> @@ -138,10 +140,9 @@ int parse_ref_filter_atom(const char *atom, const char *ep)
>>                  * shouldn't be used for checking against the valid_atom
>>                  * table.
>>                  */
>> -               const char *formatp = strchr(sp, ':');
>> -               if (!formatp || ep < formatp)
>> -                       formatp = ep;
>> -               if (len == formatp - sp && !memcmp(valid_atom[i].name, sp, len))
>> +               arg = memchr(sp, ':', ep - sp);
>
> Why this change from strchr() to memchr()? I understand that you're
> taking advantage of the fact that you know the extent of the string
> via 'sp' and 'ep', however, was the original strchr() doing extra
> work? Even if this change is desirable, it seems somewhat unrelated to
> the overall purpose of this patch, thus might deserves its own.

I think the original strchr() is a bug.  If you are given a
substring as a range, you shouldn't be allowing strchr() to go
beyond ep to find a NUL that may or may not exist.  That is not a
performance thing, but more about the best practice to ensure
correctness.  The caller of this function may not have such a
problem, but imagine the case where the bytes beyond ep did not have
any NUL and there is an unmapped page after that.

  reply	other threads:[~2016-02-04  1:17 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-31 17:42 [PATCH v4 00/12] ref-filter: use parsing functions Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 01/12] strbuf: introduce strbuf_split_str_omit_term() Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 02/12] ref-filter: use strbuf_split_str_omit_term() Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 03/12] ref-filter: bump 'used_atom' and related code to the top Karthik Nayak
2016-02-01 22:22   ` Junio C Hamano
2016-02-02 18:50     ` Karthik Nayak
2016-02-02 18:56     ` Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 04/12] ref-filter: introduce struct used_atom Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 05/12] ref-filter: introduce parsing functions for each valid atom Karthik Nayak
2016-02-03 22:19   ` Eric Sunshine
2016-02-04  1:17     ` Junio C Hamano [this message]
2016-02-06 14:36     ` Karthik Nayak
2016-02-07  7:03       ` Eric Sunshine
2016-02-07  9:03         ` Karthik Nayak
2016-02-06 15:15   ` Karthik Nayak
2016-02-07  6:33     ` Eric Sunshine
2016-02-07  9:01       ` Karthik Nayak
2016-02-07  9:12         ` Eric Sunshine
2016-02-07 13:47         ` Andreas Schwab
2016-02-09 17:00           ` Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 06/12] ref-filter: introduce color_atom_parser() Karthik Nayak
2016-02-04 22:25   ` Eric Sunshine
2016-02-06 15:20     ` Karthik Nayak
2016-02-06 15:51       ` Christian Couder
2016-02-07  7:53         ` Eric Sunshine
2016-02-07  7:43       ` Eric Sunshine
2016-02-07  9:04         ` Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 07/12] ref-filter: introduce parse_align_position() Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 08/12] ref-filter: introduce align_atom_parser() Karthik Nayak
2016-02-04 23:48   ` Eric Sunshine
2016-02-06 15:26     ` Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 09/12] ref-filter: align: introduce long-form syntax Karthik Nayak
2016-02-05  0:00   ` Eric Sunshine
2016-02-06 18:37     ` Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 11/12] ref-filter: introduce contents_atom_parser() Karthik Nayak
2016-02-05  0:22   ` Eric Sunshine
2016-02-07  4:58     ` Karthik Nayak
2016-01-31 17:42 ` [PATCH v4 12/12] ref-filter: introduce objectname_atom_parser() Karthik Nayak
2016-02-01 22:25 ` [PATCH v4 00/12] ref-filter: use parsing functions Junio C Hamano
2016-02-02  0:37   ` Eric Sunshine
2016-02-02  4:35     ` Karthik Nayak
2016-02-05  0:34   ` Eric Sunshine
     [not found] ` <1454262176-6594-11-git-send-email-Karthik.188@gmail.com>
2016-02-02  0:59   ` [PATCH v4 10/12] ref-filter: introduce remote_ref_atom_parser() Eric Sunshine
2016-02-02  2:59     ` Karthik Nayak
2016-02-05  0:05   ` Eric Sunshine
2016-02-06 18:44     ` Karthik Nayak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqa8nhjmtn.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=karthik.188@gmail$(echo .)com \
    --cc=sunshine@sunshineco$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox