Michael Haggerty <mhagger@xxxxxxxxxxxx> 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/
--
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