From: Stefan Beller <sbeller@google.com>
Date: Thu, 07 Sep 2017 20:38:51 GMT
Subject: Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives
Message-ID: <CAGZ79kahVcKY3mJdZAP3jWCBY58VbCTHCfaonTgP7TDYrV+jag@mail.gmail.com>
In-Reply-To: <20170907091734.nsdpo2dpcgvf2zna@sigill.intra.peff.net>

On Thu, Sep 7, 2017 at 2:17 AM, Jeff King <peff@peff.net> wrote:
>> After having a sneak peak at the implementation
>> it is O(1) in runtime for each added element, and the
>> space complexity is O(well).
>
> I'm not sure if your "well" is "this does well" or "well, it could be
> quite a lot". :)

Both actually. When I wrote it I thought the phonetic interpretation
was way too funny, but nobody can hear subtle humor on mailing
lists. :)

If UNLEAK is used correctly, then it sounds more like
"this does well (and we cannot do better anyway)".

> It certainly has the potential to grow the heap without bound (since
> after all, it's whole point is to make a giant list of variables that
> are going out of scope). But in practice we'd sprinkle this over a
> handful of variables just before program exit (and remember that it's
> copying only what's on the stack already; so pointers get copied, not
> whole heap-allocated blocks).
>
> Plus it does nothing at all when not compiled with leak-checking. So I'm
> not too worried about the extra memory usage or performance.

me neither.

Thanks for starting this series (I am really happy about this solution)!
Stefan