Re: strbuf API

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Sep 3, 2007, 08:32 UTC
Message-ID: <vpqk5r8m9nz.fsf@bauges.imag.fr>
In-Reply-To: <20070902224213.GB431@artemis.corp>

Pierre Habouzit <madcoder@debian.org> writes:

Show 6 quoted lines

>   First, and that's the most important one: the buffer is always NUL
> terminated, after its official "len". That means, in terms of strbuf
> API, that "alloc" is always greater or equal to len+1 to be able to
> store the ending NUL[1]. The advantages are obvious: you can pass the
> buffer to any legacy C string function without any fear of read
> overflow.

No overflow, but it's still potentially dangerous: if your strbuf contains a '\0', you can't use any standard C string function.

For example, it would be very tempting to compare files with "strcmp(buf1, buf2)", but that would just fail silently when the file contains a '\0' byte.

I don't have a perfect solution, but having something explicit to say "hey, I'm going to use a legacy C function" doesn't sound like a bad idea.

>   The other shortcoming is that you cannot tell the buffer "Hey, it's
> very likely that you'll end up being _that_ long.

100% ACK on this point.

-- 
Matthieu