William Duclot <william.duclot@xxxxxxxxxxxxxxxxxxxxxxx> writes:
> I'm not sure to follow you. I agree that the "fixed strbuf" feature is
> flawed by the presence of this `die()`. But (unless misunderstanding)
> the "owns_memory" bit you talk about does exist in this patch, and allow
> the exact behavior you describe.
Imagine that I know most of my input lines are shorter than 80 bytes
and definitely shorter than 128 bytes. I may want to say:
/* allocate initial buffer ch[128] and attach it to line */
struct strbuf line = STRBUF_INIT_ON_STACK(128);
while (!strbuf_getline(&line, stdin)) {
... use contents of &line ...
}
strbuf_release(&line);
knowing that I won't waste too much cycles and memory from heap most
of the time. Further imagine that one line in the input happened to
be 200 bytes long. After processing that line, the next call to
strbuf_getline() will call strbuf_reset(&line).
I think that call should reset line.buf to the original buffer on
the stack, instead of saying "Ok, I'll ignore the original memory
not owned by us and instead keep pointing at the allocated memory",
as the allocation was done as a fallback measure. The reason why
strbuf_reset() is different from strbuf_release() is because we
anticipate that a buffer that is reset is going to be used again
very soon and want to avoid freeing only to call another alloc
immediately. We just set its logical length to 0 without shrinking
what has already been allocated in the heap, because there is no
good hint that tells us what the optimal size of an empty
buffer in the particular caller that is waiting to be used before
this "improve API" effort.
But that "lack of hint" no longer is true with this "imporve API"
thing. We _know_ that the caller thinks the anticipated typical
workload should fit well within the 128 bytes buffer that it
originally gave us. That is what I'd expect from an "initialize a
reasonably sized piece of memory on stack and use it most of the
time in strbuf" feature.
> The patch allow to use a preallocated strbuf OR a preallocated-and-fixed
> strbuf. Does the "fixed" part is useful, that's very debatable.
"Fixed and non-extendable" is useless; there is no room for
debating.
--
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