git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karthik Nayak <karthik.188@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Junio C Hamano <gitster@pobox.com>, Git <git@vger.kernel.org>
Subject: Re: [PATCH v3 01/15] strbuf: introduce strbuf_split_str_omit_term()
Date: Mon, 25 Jan 2016 11:42:08 +0530	[thread overview]
Message-ID: <CAOLa=ZRhViUntR4yO66imd7D6KN+CCqkREGPVRfTfyN3zLQoAw@mail.gmail.com> (raw)
In-Reply-To: <CAPig+cQ2-ddENz4dKsvTW-tOrwugUGa4g-3PySMTBsHsrtO93w@mail.gmail.com>

On Fri, Jan 22, 2016 at 1:17 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Wed, Jan 6, 2016 at 2:27 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> On Wed, Jan 6, 2016 at 12:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Karthik Nayak <karthik.188@gmail.com> writes:
>>>>       while (slen) {
>>>>               int len = slen;
>>>> +             const char *end = NULL;
>>>>               if (max <= 0 || nr + 1 < max) {
>>>> -                     const char *end = memchr(str, terminator, slen);
>>>> +                     end = memchr(str, terminator, slen);
>>>>                       if (end)
>>>>                               len = end - str + 1;
>>>>               }
>>>>               t = xmalloc(sizeof(struct strbuf));
>>>>               strbuf_init(t, len);
>>>> -             strbuf_add(t, str, len);
>>>> +             strbuf_add(t, str, len - !!end * !!omit_term);
>>>
>>> Perhaps using another variable would make it easier to follow?
>>> Either using a boolean that tells us that the terminating byte
>>> is to be omitted, i.e.
>>>
>>>         int len = slen;
>>>         int omit = 0;
>>>         if ( ... we are still splitting ... ) {
>>>                 const char *end = memchr(...);
>>>                 if (end) {
>>>                         len = end - str + 1;
>>>                         omit = !!omit_term;
>>>                 }
>>>         }
>>>         strbuf_init(t, len - omit);
>>>         strbuf_add(t, str, len - omit);
>>>
>>> or an integer "copylen" that tells us how many bytes to copy, which
>>> often is the same as "len" but sometimes different by 1 byte?
>>
>> This is done based on Eric's suggestion [1]. Although its a little off normal
>> convention. I find it small and simple. So I'm okay with either, your suggested
>> change or the existing code.
>
> A "copylen" variable would probably result in the clearest code since
> it states explicitly what an otherwise opaque expression like (!!end *
> !!omit_term) means, thus is easier to reason about.

Sure, I think this would do:

diff --git a/strbuf.c b/strbuf.c
index b552a13..81e279d 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -115,7 +115,7 @@ void strbuf_tolower(struct strbuf *sb)
 }

 struct strbuf **strbuf_split_buf(const char *str, size_t slen,
-                                int terminator, int max)
+                                int terminator, int max, int omit_term)
 {
        struct strbuf **ret = NULL;
        size_t nr = 0, alloc = 0;
@@ -123,14 +123,18 @@ struct strbuf **strbuf_split_buf(const char
*str, size_t slen,

        while (slen) {
                int len = slen;
+               int copylen = len;
+               const char *end = NULL;
                if (max <= 0 || nr + 1 < max) {
-                       const char *end = memchr(str, terminator, slen);
-                       if (end)
+                       end = memchr(str, terminator, slen);
+                       if (end) {
                                len = end - str + 1;
+                               copylen = len - !!omit_term;
+                       }
                }
                t = xmalloc(sizeof(struct strbuf));
-               strbuf_init(t, len);
-               strbuf_add(t, str, len);
+               strbuf_init(t, copylen);
+               strbuf_add(t, str, copylen);
                ALLOC_GROW(ret, nr + 2, alloc);
                ret[nr++] = t;
                str += len;


-- 
Regards,
Karthik Nayak

  reply	other threads:[~2016-01-25  6:12 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-05  8:02 [PATCH v3 00/15] ref-filter: use parsing functions Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 01/15] strbuf: introduce strbuf_split_str_omit_term() Karthik Nayak
2016-01-05 19:24   ` Junio C Hamano
2016-01-06  7:27     ` Karthik Nayak
2016-01-21 19:47       ` Eric Sunshine
2016-01-25  6:12         ` Karthik Nayak [this message]
2016-01-05  8:03 ` [PATCH v3 02/15] ref-filter: use strbuf_split_str_omit_term() Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 03/15] ref-filter: bump 'used_atom' and related code to the top Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 04/15] ref-filter: introduce struct used_atom Karthik Nayak
2016-01-21 19:04   ` Eric Sunshine
2016-01-25  6:13     ` Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 05/15] ref-filter: introduce parsing functions for each valid atom Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 06/15] ref-fitler: bump match_atom() name to the top Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 07/15] ref-filter: skip deref specifier in match_atom_name() Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 08/15] ref-filter: introduce color_atom_parser() Karthik Nayak
2016-01-05 20:49   ` Junio C Hamano
2016-01-06  7:52     ` Karthik Nayak
2016-01-05 21:06   ` Junio C Hamano
2016-01-06 10:16     ` Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 09/15] ref-filter: introduce align_atom_parser() Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 10/15] ref-filter: introduce parse_align_position() Karthik Nayak
2016-01-25 21:49   ` Eric Sunshine
2016-01-26 11:34     ` Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 11/15] ref-filter: convert variable 'width' to an unsigned int Karthik Nayak
2016-01-05 21:12   ` Junio C Hamano
2016-01-06 10:17     ` Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 12/15] ref-filter: align: introduce long-form syntax Karthik Nayak
2016-01-25 22:58   ` Eric Sunshine
2016-01-25 23:45     ` Junio C Hamano
2016-01-26  9:40       ` Karthik Nayak
2016-01-26  9:30     ` Karthik Nayak
2016-01-26  5:16   ` Christian Couder
2016-01-26  9:39     ` Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 13/15] ref-filter: introduce remote_ref_atom_parser() Karthik Nayak
2016-01-26  0:28   ` Eric Sunshine
2016-01-26 10:02     ` Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 14/15] ref-filter: introduce contents_atom_parser() Karthik Nayak
2016-01-05 21:22   ` Junio C Hamano
2016-01-06 18:22     ` Karthik Nayak
2016-01-07 18:04       ` Junio C Hamano
2016-01-07 20:03         ` Karthik Nayak
2016-01-05  8:03 ` [PATCH v3 15/15] ref-filter: introduce objectname_atom_parser() Karthik Nayak
2016-01-05 21:31   ` Junio C Hamano
2016-01-06 18:27     ` Karthik Nayak
2016-01-06 21:14 ` [PATCH v3 00/15] ref-filter: use parsing functions Eric Sunshine
2016-01-07 14:25   ` Karthik Nayak
2016-01-07 18:43     ` Junio C Hamano
2016-01-07 20:20       ` Karthik Nayak
2016-01-07 20:36       ` Eric Sunshine
2016-01-07 20:44       ` Karthik Nayak
2016-01-07 21:28         ` Junio C Hamano
2016-01-09  9:00           ` 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='CAOLa=ZRhViUntR4yO66imd7D6KN+CCqkREGPVRfTfyN3zLQoAw@mail.gmail.com' \
    --to=karthik.188@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).