Hello,

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.

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.

Thanks!

Mateo <mateopatinodev@gmail.com>

[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/

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

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.

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/

(Note: resending this because it had HTML the first time and the list rejected it. Apologies if it becomes a duplicate for someone).

Yes, I saw that they did not reply to reviewer feedback. Here I meant to say that previous patches had already been attempted in this area and could be used as guidance for future attempts.

Since the Git codebase widely assumes strbuf.buf is writable, I wonder whether we could create a new struct that is specifically documented as a read-only, non-owning view into memory, something lightweight like `string_view` in C++, which is an object that simply holds a pointer to a string in memory and the length. For example, in C,

struct strview {
    const char *buf;
    size_t len;
};

This struct would not care where the memory that `buf` points to exists. The memory would be owned elsewhere and the caller would be responsible for ensuring that the memory is valid throughout the lifetime of the struct. I think this could help pass around string data without requiring ownership or allocation, particularly in cases where the data is already available.

A small downside I see to this approach is that we'd need to write a few helper functions that accompany this struct, and they would likely share similar names to the helper functions of `strbuf`, though I think this has been accepted in the past in other places throughout the codebase.

Another consideration is that this proposed `strview` would not address the lifetime and ownership issue in [4], but having a safer way to pass read-only strings seems like a step in the right direction.

On Mon, Mar 23, 2026 at 1:11 AM Mateo Patino <mateopatinodev@gmail.com> wrote:

I think this is a solution to a non-existent problem. Being written in C, Git does not (generally) have a need for this sort of structure. When Git code wants to "pass around" an immutable string to functions, those functions simply declare themselves as accepting a const string, as in:

    void do_something(const char *s) {...}

In the less common case that the string is not NUL-terminated or only a portion of the string should be processed, the function also takes a length:

    void do_something(const char *s, size_t n) {...}

This is a common idiom in the Git codebase, it's perfectly safe, doesn't involve ownership concerns, and there is no reason to stray away from it. The proposed `strview` is not safer and is probably not as convenient, thus adds no apparent value.

But, having reread the threads which your initial email referenced, I think the bigger issue is that we're dealing with an XY Problem[1]. The original problem "X" being discussed was how to achieve static initialization of some string variables while still allowing the variables to be later pointed at heap-allocated memory, but at the same time avoiding memory leaks when those reassignments occur. The proposed solution "Y" was to somehow employ `strbuf` to solve X, however, it turns out that `strbuf` is utterly unsuitable for this use-case. Unfortunately, this "Y" proposal was then turned into a GitHub issue[2] which has led to this email thread as well as those aborted and misdirected submissions which you referenced earlier.

If we take a step back and focus on the original problem rather than focusing on how to twist strbuf into something it was never meant to be, then a potential solution becomes clearer. Let's restate the original problem:

  static const char *global_var = "thimble";

  void maybe_assign(const char **var, ...) {
    if (...some_condition...) {
      /* ??? free((void *)*var) ??? */
      *var = some_heap_allocated_str;
    }
  }

  maybe_assign(&global_var, ...);
  ...
  maybe_assign(&global_var, ...);

When maybe_assign() is called, it doesn't know whether or not the incoming `var` points at a static string literal ("thimble") or at some heap-allocated string, so it doesn't know whether or not to first free() `var` before assigning the new value. To solve this, we need a flag which indicates whether the string stored in the variable needs to be freed before the variable is reassigned. So, this suggests a dedicated, simple structure and a few related functions and a macro or two. For instance, something like this:

  struct str {
    char *s;
    int free_me;
  };

  /* initialize `str` from a literal string (i.e. "foo") */
  #define STR_INIT(X) { .s = (char *)(X), .free_me = 0 }

  void str_release(str *x) {
    if (x.free_me)
      FREE_AND_NULL(x.s);
    x.free_me = 0;
  }

  /* take ownership of a heap-allocated string */
  void str_take(str *x, char * s) {
    str_release(x);
    x.s = s;
    x.free_me = 1;
  }

  /* assign a string literal (i.e. "foo") */
  void str_assign(str *x, const char *s) {
    str_release(x);
    x.s = (char *)s;
    x.free_me = 0;
  }

That's probably about all you need to solve the stated problem. Given the above, the original problem statement can be "fixed" by taking advantage of the above structure and functions:

  static struct str global_var = STR_INIT("thimble");

  void maybe_assign(str *var, ...) {
    if (...some_condition...)
      str_assign(var, some_heap_allocated_str);
  }

  maybe_assign(&global_var, ...);

Clients which need the value simply access the `.s` member directly. And there is no need to have any functions to morph the string in any way. If a client needs that functionality, it is easy enough to create and populate a proper `strbuf` from the `.s` member.

[1]: https://xyproblem.info/ [2]: https://github.com/gitgitgadget/git/issues/398

I didn't know this concept of an XY problem. It seems very useful to describe this kind of mistake in software development. I will keep it in mind from now on. Thanks for sharing it!

Thanks for explaining the original problem in such detail, I see I really hadn't completely understood what the original problem "X" was.

To clarify, you are imagining this `struct str` more as a "smart pointer" than a full string abstraction, correct? I was going to propose including a `size_t len` member for this struct, but after some thought, I feel like that would somewhat transform `struct str` into a string abstraction, which `strbuf` already is. The way you're imagining `struct str` could be used around in the Git codebase is as a wrapper whose only purpose is to inform clients of a string's ownership, correct?

So if we were to make this into a patch, would we implement this as a local helper in config.c, where the original problem started? I imagine this small ownership interface could likely be used in multiple places around the codebase, so my first instinct would be to not restrict it to config.c. Would it be too premature to give this `struct str` its own module? If so, then how would an idea of this sort be first presented to the community as a patch?

Thanks again for the detailed explanations!

On Sat, Mar 28, 2026 at 5:41 PM Mateo Patino <mateopatinodev@gmail.com> wrote:

You're correct that I'm not proposing a full string abstraction; however, I wouldn't exactly call it a smart-pointer or say that it "informs" clients of a string's ownership. It's just a tool which makes it simple for clients to reassign the string without having to worry about the ownership.

Whether or not it would be generally helpful throughout the Git codebase remains to be seen.

By the way, the above example using the "free_me" member was just for illustration purposes since "free_me" makes the ownership concerns obvious. However, in practice, a better approach would be to employ the "to_free" idiom which is used elsewhere in the Git codebase since it avoids all the ugly casts. Something like this:

  struct str {
    const char *s;
    char *to_free; /* private */
  };

  /* initialize `str` from a literal string (i.e. "foo") */
  #define STR_INIT(X) { .s = (X), .to_free = NULL }

  void str_release(struct str *x) {
    x.s = NULL;
    FREE_AND_NULL(x.to_free);
  }

  /* take ownership of a heap-allocated string */
  void str_take(struct str *x, char *s) {
    str_release(x);
    x.s = s;
    x.to_free = s;
  }

  /* assign a string literal (i.e. "foo") */
  void str_assign(struct str *x, const char *s) {
    str_release(x);
    x.s = s;
  }

My gut feeling is that it would make sense first to introduce such a utility locally in `config.c` where it is needed. If it becomes apparent that it has value outside of `config.c`, then it could be extracted into a reusable component. However, others may feel differently, and even I don't feel strongly about it.

One reason I hesitate to suggest that this would be generally useful is that the existing "to_free" idiom employed in Git is already about as simple as it gets, and I don't think the proposed "str" utility would necessarily make it any simpler or improve code quality. For instance, a typical use of "to_free" might be something like this:

  const char *name = "default";
  char *to_free = NULL;
  ...do stuff...
  if (some_condition)
    name = to_free = xstrdup(some_str_var);
  ...do stuff...
  free(to_free);

Changing this to take advantage of the proposed "str" might result in:

  struct str name = STR_INIT("default");
  ...do stuff...
  if (some_condition)
    str_take(&name, xstrdup(some_str_var));
  ...do stuff...
  str_release(&name);

which is only one line shorter, and not necessarily any clearer or less noisy. So, there isn't a strong reason (outside of `config.c`) to convert such code to use "str", and any such conversion just for the sake of conversion would probably be unwanted churn.