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

[Mateo Patino <mateopatinodev@gmail.com>]

(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.