Michael Haggerty mhag...@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
On 04/22/2014 09:07 AM, Matthieu Moy wrote:
Michael Haggerty mhag...@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)
Michael Haggerty mhag...@alum.mit.edu 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
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
Michael Haggerty mhag...@alum.mit.edu 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
On 04/18/2014 07:21 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu writes:
On 04/18/2014 07:21 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
7 matches
Mail list logo
