Re: Project idea: strbuf allocation modes

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 18, 2014, 17:21 UTC
Message-ID: <xmqq8ur2d04g.fsf@gitster.dls.corp.google.com>
In-Reply-To: <53512DB6.1070600@alum.mit.edu>

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

Show 7 quoted lines

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