Re: Project idea: strbuf allocation modes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]