Re: Project idea: strbuf allocation modes

[Michael Haggerty <mhagger@alum.mit.edu>]

On 04/18/2014 07:21 PM, Junio C Hamano wrote:
> 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.

I think that's exactly what I described.  The only thing that would have
to change in the strbuf behavior (aside from initialization) is that a
buffer-growing operation might die if the string would grow outside of
the bounds of the existing buffer when STRBUF_FIXED_MEMORY is set.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/