Re: [RFC] [GSoC]: STRBUF_INIT_CONST: initialize `strbuf` to constant string

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Mar 22, 2026, 08:59 UTC
Message-ID: <CAPig+cRAsEgeT+OgCSpTuY_Q6dMpXrfadrB=ujkAUyF-ocu2-g@mail.gmail.com>
In-Reply-To: <20260322065509.5384-1-mateopatinodev@gmail.com>

On Sun, Mar 22, 2026 at 2:55 AM Mateo Patino <mateopatinodev@gmail.com> wrote:

Show 15 quoted lines

> My name is Mateo, and I'm a new contributor to Git. I'm a 1st year
> undergrad at Columbia University studying CS and applied math.
>
> I wanted to ask the community for feedback on a project proposal
> regarding the `strbuf` API. Seven years ago, a macro to initialize a
> `strbuf` to a constant string literal was proposed in GitGitGadget [1]
> called `STRBUF_INIT_CONST`. This macro would work just like `STRBUF_INIT`
> but it would set `alloc` to 0 (i.e. the buffer would not be
> heap-allocated).
>
> Someone made a pull request to implement this feature [2], but their
> changes were not merged. Later, Robear Selwans made a patch series [3]
> attempting to implement this same feature. Robear got extensive
> feedback, but his patches were not accepted. The same GitHub user from
> [2] sent a patch here [4], but his changes were not accepted.

You probably didn't intend for it to sound this way, but this summary makes it seem as if the Git project rejected these patch submissions without proper justification. However, having studied the threads which you referenced, it becomes clear that the reason these patches were never accepted is because the submitters never followed through by addressing reviewer comments. For instance, in my review[*1*] of the patch [4] which you referenced, I pointed out several significant problems with the patch, but the patch author never responded, so it makes sense that the submission was never accepted into the project.

Show 14 quoted lines

> More recently, the potential need for `STRBUF_INIT_CONST` was mentioned
> in this patch series [5] by Patrick Steinhardt, though it was marked
> as a #leftoverbit and not directly addressed.
>
> `STRBUF_INIT_CONST` has been mentioned for a long time in this list,
> but it has not been implemented yet. My Request For Comment is the
> following: is `STRBUF_INIT_CONST` a feature that is still of interest
> to the community? If so, I would like to make a GSoC proposal around it.
> The past email threads have already laid out the considerations of
> implementing `STRBUF_INIT_CONST` or something equivalent, so I would
> like to propose this as GSoC idea if the community would find it
> worthwhile.
>
> I would love to hear any thoughts about this.

Although feedback to Robear Selwans's submission from some reviewers was subjective, Peff's review[*2*] pointed at a major roadblock; specifically, that strbuf has always promoted strbuf.buf is a writeable C-style string, so it is not safe simply to assign a pointer to a literal string to the "buf" member, and it's not practical to expect that all consumers of strbufs can be audited and modified to work correctly with the "new world order" that STRBUF_INIT_CONST would introduce.

Thus, the issue is deeper than it may seem at first glance, and unless you have some fundamentally new ideas to address the sort of critical issues identified by such feedback, it is likely that a patch which takes an approach similar to what has previously been submitted will likewise fail.

[*1*]: https://lore.kernel.org/git/CAPig+cQL=b-nF6nADaWueJaDmxCgmZbUwWj6=dAwYQ=vVrkifg@mail.gmail.com/ [*2*]: https://lore.kernel.org/git/20200218062124.GF1641086@coredump.intra.peff.net/

Show 5 quoted lines

> [1] https://github.com/gitgitgadget/git/issues/398
> [2] https://github.com/gitgitgadget/git/pull/824
> [3] https://lore.kernel.org/git/20200218041805.10939-1-robear.selwans@outlook.com/
> [4] https://lore.kernel.org/git/20210105064502.725307-1-adlternative@gmail.com/
> [5] https://lore.kernel.org/git/Zrm9ix5aN_g76Qxq@tanuki/