From: Jeff King <peff@peff.net>
To: Taylor Blau <me@ttaylorr.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: tb/ban-strtok (was: Re: What's cooking in git.git (Apr 2023, #06; Thu, 20))
Date: Sat, 22 Apr 2023 07:22:13 -0400 [thread overview]
Message-ID: <20230422112213.GE2969939@coredump.intra.peff.net> (raw)
In-Reply-To: <ZEHyBbKN5MuxqfQn@nand.local>
On Thu, Apr 20, 2023 at 10:16:37PM -0400, Taylor Blau wrote:
> On Thu, Apr 20, 2023 at 03:34:26PM -0700, Junio C Hamano wrote:
> > * tb/ban-strtok (2023-04-18) 6 commits
> > - banned.h: mark `strtok()` as banned
> > - t/helper/test-json-writer.c: avoid using `strtok()`
> > - t/helper/test-oidmap.c: avoid using `strtok()`
> > - t/helper/test-hashmap.c: avoid using `strtok()`
> > - string-list: introduce `string_list_setlen()`
> > - string-list: introduce `string_list_split_in_place_multi()`
> >
> > Mark strtok() and strtok_r() to be banned.
>
> The latest round bans only strtok(), so this description would need
> updating (probably to something as simple as "Mark strtok() as banned").
>
> > Comments?
>
> I would be curious to get Peff's (cc'd) thoughts on this series, since
> it was something that he and I were talking about off-list. It was one
> of those "let me see how hard this would be..." topics, that by the time
> I finished investigating, I had the series ready to go.
I left a few small comments on the series.
On the greater question of "should strtok or strtok_r be banned", I
don't have too strong a feeling. The hidden global state in strtok() is
bad, so probably worth outlawing.
I tend to think that strtok_r() is a bit confusing to use. As Chris
noted, strsep() is better, but not necessarily as portable. Using
ptr/len pairs to parse via strcspn(), etc, seems better still. But that
is mostly aesthetics and preference, so I'm OK if we don't outright ban
strtok_r().
-Peff
next prev parent reply other threads:[~2023-04-22 11:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 22:34 What's cooking in git.git (Apr 2023, #06; Thu, 20) Junio C Hamano
2023-04-21 2:16 ` tb/ban-strtok (was: Re: What's cooking in git.git (Apr 2023, #06; Thu, 20)) Taylor Blau
2023-04-22 11:22 ` Jeff King [this message]
2023-04-24 16:39 ` tb/ban-strtok Junio C Hamano
2023-04-22 15:00 ` en/header-split-cache-h-part-2 (Was: Re: What's cooking in git.git (Apr 2023, #06; Thu, 20)) Elijah Newren
2023-04-24 18:20 ` en/header-split-cache-h-part-2 Junio C Hamano
2023-04-22 15:00 ` pb/complete-and-document-auto-merge-and-friends (Was: Re: What's cooking in git.git (Apr 2023, #06; Thu, 20)) Elijah Newren
2023-04-22 21:53 ` Philippe Blain
2023-04-24 18:21 ` pb/complete-and-document-auto-merge-and-friends Junio C Hamano
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=20230422112213.GE2969939@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.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 read-only IMAP folder(s) and NNTP newsgroup(s).