Allright, here is a proposal for a new strbuf semantics like the one I proposed before. Like said, with this proposal, strbuf's always have a '\0' at the end of the buffer, not accounted in its length, so that any C str* function can still be used. The second patch demonstrate that strbufs makes the code smaller, simpler to read, while keeping the exact same efficiency (as may mallocs, memcpys, and fread's in that case). I've tried to keep the amount of inlines low. Though, I wonder if strbuf_add shouldn't be inlined (so that memcpys could be even more inlined/optmized by gcc). And strbuf_addstr is inlined so that the strlen call is optimized when the argument is an immediate string. Meaning that calling strbuf_addstr(sb, "foo") is not sloppy at all. I don't really like the buffer growth scheme right now, I just stick with the one that was used in git before. Though I really belive it's inelegant as is, and should be simplified (strbuf_extend). Cheers, -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org - 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
