On Wed, Feb 06, 2008 at 10:10:30PM +0000, Daniel Barkalow wrote: > On Wed, 6 Feb 2008, Pierre Habouzit wrote: > > > On Wed, Feb 06, 2008 at 08:31:08PM +0000, Junio C Hamano wrote: > > > I wonder how the rule established by b315c5c (strbuf change: be > > > sure ->buf is never ever NULL) and at the beginning of strbuf.h > > > applies here. I think the current implementation of strbuf > > > happens to allow this, and it is very handy. Perhaps the rule > > > stated there should be loosened and allow copying the buf away > > > when you know you have stuff in there (i.e. ->buf != slopbuf). > > > Pierre, what do you think? > > > > > > What the patch does itself is much nicer than the original. > > > > Why wouldn't you just use strbuf_detach ? I mean replacing: > > > > + info->message_id = buf.buf; > > > > with: > > > > + info->message_id = strbuf_detach(&buf, NULL); > > > > isn't really hard to read, and has the nice side effect to prevent > > errors that could happen in the future (like reusing buf and screwing > > with info->message_id without noticing it). I'd rather stand on the safe > > side here, it's more forward-compatible and idiot-proof[0]. > > Is it actually right to have buf go out of scope right after > strbuf_detach()? It sort of looks like it would leak memory from buf.buf. > I'm happy to do whatever the API wants there, and I didn't see anything to > leave the struct as if strbuf_release were called, but with the string > extracted for the caller. err no, strbuf_detach gives you a pointer you are supposed to free() later, and inits the strbuf passed as its argument to be used again, though if you don't, you leak nothing. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpNOxSlwnAAu.pgp
Description: PGP signature
