All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.