On 04/18/2014 07:21 PM, Junio C Hamano wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> 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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html