Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> I'd rather see your reroll with the above addition of UNLEAK() than >> without it, to fix the breakage. > > I don't mind that UNLEAK() being in-tree until a better fix for that > leak, but doesn't the v5 I sent also address this? > > The issue was that I mis-marked a test as passing, when it only passed > depending on my local compiler (-fsanitize=leak is fickle > sometimes). Now that we're not marking that test as leak-free there's no > need for the UNLEAK() for now, no? > > Or is there some edge case I didn't spot/notice? The top-level singleton instance of "filter" that is used once and never grows unbounded is a perfect use case for UNLEAK(). And with it, the test DOES get leak-free, so it would be appropriate to keep the PASSES variable added to the script (until it gets broken again). Or did you have any other uses of tools with leaks in the script, other than the one that is fixed with the UNLEAK()?
