Re: Project idea: strbuf allocation modes

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

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

>     STRBUF_OWNS_MEMORY
>
>         The memory pointed to by buf is owned by this strbuf.  If this
>         bit is not set, then the memory should never be freed, and
>         (among other things) strbuf_detach() must always call xstrcpy().

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?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/