From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org, "Philip Oakley" <philipoakley@iee.email>
Subject: Re: [PATCH v2 0/7] strvec: use size_t to store nr and alloc
Date: Sun, 12 Sep 2021 22:38:11 -0700 [thread overview]
Message-ID: <xmqqlf41ghmk.fsf@gitster.g> (raw)
In-Reply-To: YT586/CO7QsTb3TK@coredump.intra.peff.net
Jeff King <peff@peff.net> writes:
> I'm a little "meh" on some of these, for a few reasons:
>
> - anything calling into setup_revisions() eventually is just kicking
> the can anyway. And these are generally not buggy in the first place,
> since they're bounded argv creations.
>
> - passing a strvec instead of the broken-down pair is a less flexible
> interface. It's one thing if the callee benefits from seeing the
> strvec (say, because they may push more items onto it). But I think
> with strbufs, we have a general guideline that if a function _can_
> take the bare pointer, then it should. (Sorry, I don't have a
> succinct reference to CodingGuidelines or anything like that; I feel
> like this is wisdom we came up with on the list in the early days of
> strbufs).
>
> - if we are going to pass a strvec, it should almost certainly be
> const, to make it clear how we intend to use it.
All true.
> These cases are largely stupid things that real people would never come
> across. The real goal is making sure we don't get hit with a memory
> safety bug (under-allocation, converting a big size_t to a negative int,
> etc).
Yes.
Ævar, I do not mean any disrespect to you, but I have to say that
topics like this one are starting to wear my concentration and
patience down really thin and making me really slow down.
Perhaps I am biased by not yet having seen what you eventually want
to build on top, and because of that I do not understood why and how
these "clean ups" are so valuable to have right now (as opposed to
just letting the sleeping dog lie), which you would of course have a
much better chance to know than I do.
But with that "bias", many of the recent patches from you look more
like pointless churn, mixed with fixes to theoretical problems, than
clean-ups with real benefits.
What makes it worse is that there are occasional real gems among
these "meh" patches, which means I have to read all of them anyway
to sift wheat from chaff X-<.
next prev parent reply other threads:[~2021-09-13 5:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-11 15:01 [PATCH] strvec: use size_t to store nr and alloc Jeff King
2021-09-11 16:13 ` Ævar Arnfjörð Bjarmason
2021-09-11 22:48 ` Philip Oakley
2021-09-12 0:15 ` [PATCH v2 0/7] " Ævar Arnfjörð Bjarmason
2021-09-12 0:15 ` [PATCH v2 1/7] remote-curl: pass "struct strvec *" instead of int/char ** pair Ævar Arnfjörð Bjarmason
2021-09-12 0:36 ` Carlo Arenas
2021-09-13 3:56 ` Ævar Arnfjörð Bjarmason
2021-09-12 0:15 ` [PATCH v2 2/7] pack-objects: " Ævar Arnfjörð Bjarmason
2021-09-12 0:15 ` [PATCH v2 3/7] sequencer.[ch]: " Ævar Arnfjörð Bjarmason
2021-09-12 0:15 ` [PATCH v2 4/7] upload-pack.c: " Ævar Arnfjörð Bjarmason
2021-09-12 0:15 ` [PATCH v2 5/7] rebase: don't have loop over "struct strvec" depend on signed "nr" Ævar Arnfjörð Bjarmason
2021-09-12 2:57 ` Eric Sunshine
2021-09-12 0:15 ` [PATCH v2 6/7] strvec: use size_t to store nr and alloc Ævar Arnfjörð Bjarmason
2021-09-12 0:15 ` [PATCH v2 7/7] strvec API users: change some "int" tracking "nr" to "size_t" Ævar Arnfjörð Bjarmason
2021-09-12 3:00 ` Eric Sunshine
2021-09-12 22:19 ` [PATCH v2 0/7] strvec: use size_t to store nr and alloc Jeff King
2021-09-13 5:38 ` Junio C Hamano [this message]
2021-09-13 12:29 ` Ævar Arnfjörð Bjarmason
2021-09-13 17:20 ` Jeff King
2021-09-13 10:47 ` Philip Oakley
2021-09-12 22:00 ` [PATCH] " Jeff King
2021-09-13 11:42 ` Philip Oakley
2021-09-12 21:58 ` Jeff King
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqlf41ghmk.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=philipoakley@iee.email \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).