On Wed, May 29, 2024 at 01:25:02PM +0200, Patrick Steinhardt wrote: > > If we really cared, though, I think you could check sb->alloc before the > > call to getdelim(), and then we'd know whether the original held an > > allocation or not (and we could restore its state). That's what other > > syscall-ish strbuf functions like strbuf_readlink() and strbuf_getcwd() > > do. > > Ah, I didn't know that we did similar things in other strbuf functions. > With that precedence I think it's less ugly to do this dance. Yeah, I probably should have explained that better in my earlier email. ;) > > I saw only one questionable case. builtin/difftool.c does: > > > > if (strbuf_getline_nul(&lpath, fp)) > > break; > > > > without freeing lpath. But then...it does not free it in the case that > > we got a value, either! So I think it is leaking either way, and the > > solution, to strbuf_release(&lpath) outside of the loop, would fix both > > cases. > > Indeed. We also didn't free `rpath` and `info`. I do have a follow up to > this series already, so let me add those leak fixes to it. Great! Thanks (as usual) for being receptive to me piling more things on your todo list. :) -Peff
