Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

William Duclot <william.duclot@ensimag.grenoble-inp.fr> writes:

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.

"Fixed and non-extendable" is useless; there is no room for debating.