On Mon, Sep 03, 2007 at 08:32:16AM +0000, Matthieu Moy wrote: > Pierre Habouzit <madcoder@xxxxxxxxxx> writes: > > > 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. > > 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@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgp8XeMLAQxun.pgp
Description: PGP signature
