git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 01/11] strbuf: introduce strbuf_split_str_without_term()

From
Karthik Nayak <karthik.188@gmail.com>
Date
Dec 17, 2015, 08:24 UTC
Message-ID
<CAOLa=ZTDjo=eXWes1Ryzpj81gBoO7Lto3jEMGaeFioBfK_YOxA@mail.gmail.com>
In-Reply-To
<CAPig+cQcCGVuzqYT3zXUMK=sF+QLCXUbbzcoqmaAe2zf+faWsA@mail.gmail.com>
On Thu, Dec 17, 2015 at 2:05 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 12 quoted lines
> On Wed, Dec 16, 2015 at 10:29 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> strbuf: introduce strbuf_split_str_without_term()
>
> s/without/omit/
>
>> The current implementation of 'strbuf_split_buf()' includes the
>> terminator at the end of each strbuf post splitting. Add an option
>> wherein we can drop the terminator if desired. In this context
>> introduce a wrapper function 'strbuf_split_str_without_term()' which
>
> s/without/omit/
>
Oops! will change that,
Show 67 quoted lines
>> splits a given string into strbufs without including the terminator.
>>
>> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
>> ---
>> diff --git 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,15 @@ struct strbuf **strbuf_split_buf(const char *str, size_t slen,
>>
>>         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);
>
> This version of the patch with its minimal[1] change is much easier to
> review for correctness than the original attempt[2].
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/281882
> [2]: http://article.gmane.org/gmane.comp.version-control.git/281189
>
>>                 ALLOC_GROW(ret, nr + 2, alloc);
>>                 ret[nr++] = t;
>>                 str += len;
>> diff --git a/strbuf.h b/strbuf.h
>> index 6ae7a72..a865a74 100644
>> --- a/strbuf.h
>> +++ b/strbuf.h
>> @@ -450,11 +450,12 @@ static inline int strbuf_strip_suffix(struct strbuf *sb, const char *suffix)
>>  /**
>>   * Split str (of length slen) at the specified terminator character.
>>   * Return a null-terminated array of pointers to strbuf objects
>> - * holding the substrings.  The substrings include the terminator,
>> - * except for the last substring, which might be unterminated if the
>> - * original string did not end with a terminator.  If max is positive,
>> - * then split the string into at most max substrings (with the last
>> - * substring containing everything following the (max-1)th terminator
>> + * holding the substrings.  The substrings include the terminator if
>> + * the value of omit_term is '0' else the terminator is excluded.  The
>
> Perhaps just say "if omit_term is false" rather than "if the value of ... is 0".
>
>> + * last substring, might be unterminated if the original string did
>> + * not end with a terminator.  If max is positive, then split the
>
> This bit about the last substring is perhaps too disconnected from the
> previous sentence. What if you re-word the entire thing something like
> this:
>
>     If omit_term is true, the terminator will be stripped from all
>     substrings. Otherwise, substrings will include the terminator,
>     except for the final substring, if the original string lacked a
>     terminator.
>
Im quite bad at this, thanks :)
Show 5 quoted lines
>>
>> This version of the patch with its minimal[1] change is much easier to
>> review for correctness than the original attempt[2].
>
> Perhaps worthy of a Helped-by:?
Definitely! Sorry for not including that, slipped off my mind.
-- 
Regards,
Karthik Nayak
Previous: Eric SunshineNext: Karthik Nayak
Message 4 of 34 in “ref-filter: use parsing functions”
  1. 00/11 ref-filter: use parsing functionsKarthik Nayak, Dec 16, 2015
  2. 01/11 strbuf: introduce strbuf_split_str_without_term()Karthik Nayak, Dec 16, 2015
  3. Eric SunshineDec 16, 2015
  4. Karthik NayakDec 17, 2015
  5. 02/11 ref-filter: use strbuf_split_str_omit_term()Karthik Nayak, Dec 16, 2015
  6. 03/11 ref-filter: introduce struct used_atomKarthik Nayak, Dec 16, 2015
  7. Eric SunshineDec 16, 2015
  8. Karthik NayakDec 19, 2015
  9. 04/11 ref-fitler: bump match_atom() name to the topKarthik Nayak, Dec 16, 2015
  10. 05/11 ref-filter: skip deref specifier in match_atom_name()Karthik Nayak, Dec 16, 2015
  11. Eric SunshineDec 16, 2015
  12. Karthik NayakDec 19, 2015
  13. 06/11 ref-filter: introduce color_atom_parser()Karthik Nayak, Dec 16, 2015
  14. Eric SunshineDec 16, 2015
  15. Karthik NayakDec 19, 2015
  16. 07/11 ref-filter: introduce align_atom_parser()Karthik Nayak, Dec 16, 2015
  17. Eric SunshineDec 16, 2015
  18. Karthik NayakDec 19, 2015
  19. Karthik NayakDec 19, 2015
  20. Eric SunshineDec 18, 2015
  21. 08/11 ref-filter: introduce prefixes for the align atomKarthik Nayak, Dec 16, 2015
  22. Eric SunshineDec 17, 2015
  23. Karthik NayakDec 31, 2015
  24. 09/11 ref-filter: introduce remote_ref_atom_parser()Karthik Nayak, Dec 16, 2015
  25. Eric SunshineDec 17, 2015
  26. Karthik NayakDec 24, 2015
  27. 10/11 ref-filter: introduce contents_atom_parser()Karthik Nayak, Dec 16, 2015
  28. Eric SunshineDec 17, 2015
  29. Karthik NayakDec 24, 2015
  30. 11/11 ref-filter: introduce objectname_atom_parser()Karthik Nayak, Dec 16, 2015
  31. Eric SunshineDec 18, 2015
  32. Karthik NayakDec 25, 2015
  33. Eric SunshineDec 25, 2015
  34. Karthik NayakDec 25, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.