From: Mateo Patino Date: Mon, 23 Mar 2026 16:10:51 GMT Subject: Re: [RFC] [GSoC]: STRBUF_INIT_CONST: initialize `strbuf` to constant string Message-ID: <20260323161101.9142-1-mateopatinodev@gmail.com> In-Reply-To: (Note: resending this because it had HTML the first time and the list rejected it. Apologies if it becomes a duplicate for someone). > > 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. 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. > > 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. 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.