Re: Project idea: strbuf allocation modes

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> The Idea
> ========
>
> I would like to see strbuf enhanced to allow it to use memory that it
> doesn't own (for example, stack-allocated memory), while (optionally)
> allowing it to switch over to using allocated memory if the string grows
> past the size of the pre-allocated buffer.

I'd like to see these characteristics, but I would want to see that
this is done entirely internally inside the strbuf implementation
without any API impact, other than the initialisation.  I do not
think the current API contract is too rigid to allow us doing so.

 - The API users may peek strbuf.buf in-place until they perform an
   operation that makes it longer (at which point the .buf pointer
   may point at a new piece of memory).

 - The API users may strbuf_detach() to obtain a piece of memory
   that belongs to them (at which point the strbuf becomes empty),
   hence needs to be freed by the callers.

As long as the above two promises are kept intact, it is all
internal to the strbuf implementation, current iteration of which
does not have any initial (possibly static) allocation other than
the fixed "terminating NUL", but your updated one may take a caller
supplied piece of memory that is designed to outlive the strbuf
itself as its initial allocation and the memory ownership can be
left as an internal implementation detail to the strbuf without
bothering the callers.