On 06/12/2014 09:10 AM, Jeremiah Mahler wrote:
> On Wed, Jun 11, 2014 at 02:05:35PM +0200, Michael Haggerty wrote:
>> [...]
>> If there were a function like strbuf_grow_to(sb, len):
>>
>> void strbuf_grow_to(struct strbuf *sb, size_t len)
>> {
>> int new_buf = !sb->alloc;
>> if (unsigned_add_overflows(len, 1))
>> die("you want to use way too much memory");
>> if (new_buf)
>> sb->buf = NULL;
>> ALLOC_GROW(sb->buf, len + 1, sb->alloc);
>> if (new_buf)
>> sb->buf[0] = '\0';
>> }
>>
> grow_to() which could reduce in size, interesting.
I don't understand what you mean by "could reduce in size". This
function can only grow, never reduce, the size of the strbuf, because
ALLOC_GROW doesn't do anything unless the requested size is larger than
the currently-allocated size.
>> (strbuf_grow() could call it:
>>
>> static inline void strbuf_grow(struct strbuf *sb, size_t extra)
>> {
>> if (unsigned_add_overflows(sb->len, extra))
>> die("you want to use way too much memory");
>> strbuf_grow_to(sb, sb->len + extra);
>> }
>>
>> ), then your function could be minimized to
>>
>> void strbuf_set(struct strbuf *sb, const void *data, size_t len)
>> {
>> strbuf_grow_to(sb, len);
>> memcpy(sb->buf, data, len);
>> strbuf_setlen(sb, len);
>> }
>>
>> I think strbuf_grow_to() would be useful in other situations too.
>>
>> This is just an idea; I'm not saying that you have to make this change.
>>
> I like your idea. I am leaning towards doing the un-optimized
> strbuf_set operations first, then optimizing in a later patch.
That's a good plan.
In case you're interested, I sketched what the strbuf_grow_to() changes
might look like, and also looked for other places in the code where
strbuf_grow_to() could be used instead of strbuf_grow() [1]. This is
only a sketch; I haven't even tested the result. Feel free to use what
you want from it.
Michael
[1] Branch "strbuf-grow-to-sketch" on https://github.com/mhagger/git
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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