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. 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 - 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
