Michael Haggerty writes:
> On 04/22/2014 09:07 AM, Matthieu Moy wrote:
>
> The whole point of the change is to *allow* strbuf to be used in
> performance-critical stuff.
OK. It should not make the current use of strbuf any harder anyway.
>> In your proposal, would STRBUF_OWNS_MEMORY be a consta
On 04/22/2014 09:07 AM, Matthieu Moy wrote:
> Michael Haggerty 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() mus
Michael Haggerty 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 diff
Michael Haggerty writes:
> On 04/18/2014 07:21 PM, Junio C Hamano wrote:
>> Michael Haggerty 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
On 04/18/2014 07:21 PM, Junio C Hamano wrote:
> Michael Haggerty 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
Michael Haggerty 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-al
I like that strbuf is getting used more than it used to, and I think
that is a good general trend to help git rid of and/or avoid buffer
overflows and arbitrary limits on strings.
It is unfortunate that it is currently impossible to use a strbuf
without doing a memory allocation. So code like
7 matches
Mail list logo
