Re: strbuf API

On Mon, Sep 03, 2007 at 08:32:16AM +0000, Matthieu Moy wrote:

Pierre Habouzit [off-list ref] writes:

quoted

  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.

  Indeed, OTHO doing that would be pretty silly, as embending NULs in a
strbuf is wrong, it's a _str_buf, not a random-binary-buffer. It's meant
to make the use of strings easier, not to use as generic purpose byte
buffers. Of course they can, but well, it's not what they are designed
for in the first place.

  Also note that it generates bugs, but never crashes if you still do
that, bugs suck, but security bugs, buffer overflows, ... suck more.

  So I'm tempted to say, it's not really a problem.

quoted

  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.

  Also note that it seems that bstring lack this, but maybe I'm wrong.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org