Re: Project idea: strbuf allocation modes

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

I just foresee a small difficulty from the caller side:

            char path_buf[PATH_MAX];
            char *detached;

            struct strbuf path;

            strbuf_wrap_preallocated(&path, path_buf, 0, sizeof(path));
            ...
            detached = strbuf_detach(&path);

the wrapping/unwrapping of path_buf magically turned a stack-allocated buffer into a heap-allocated one. And the initial goal of avoiding malloc() is defeated. So, essentially, one should avoir using strbuf_wrap_preallocated with strbuf_detach, right? But I agree with Junio that if the API is properly used, everything should work. I'm just worried that we will add a bit more complexity to the API, and I'm not sure we can actually expect noticeable improvements in terms of performance (i.e. do we actually use strbuf for performance-critical stuff?).

In your proposal, would STRBUF_OWNS_MEMORY be a constant, or a flag that change when the internal buffer needs reallocation? My understanding is that it should change (if STRBUF_FIXED_MEMORY is not set), and the strbuf wrapping a preallocated buffer would become a "normal" strbuf when its internal buffer grows.

If so, your "strbuf_detach() must always call xstrcpy()" is to be understood as "if STRBUF_OWNS_MEMORY is still set when strbuf_detach() is called, then it must always call xstrcpy()", right?