On 11/18/20 2:20 PM, Martin Sebor wrote:
> On 11/18/20 1:41 PM, David Malcolm wrote:
>
>> So hopefully that gives us a way forward. I'm about to disappear for a
>> week and a half, so don't let my analyzer patches stand in the way of
>> Martin's. I can finish reworking my stuff on top of Marti
On 11/18/20 1:41 PM, David Malcolm wrote:
On Mon, 2020-11-16 at 17:49 -0700, Martin Sebor wrote:
On 11/13/20 2:44 PM, Jeff Law via Gcc-patches wrote:
On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote:
This work-in-progress patch generalizes the malloc/free problem-
checking
in -fanalyzer
On Mon, 2020-11-16 at 17:49 -0700, Martin Sebor wrote:
> On 11/13/20 2:44 PM, Jeff Law via Gcc-patches wrote:
> > On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote:
> > > This work-in-progress patch generalizes the malloc/free problem-
> > > checking
> > > in -fanalyzer so that it can work on
On 11/13/20 2:44 PM, Jeff Law via Gcc-patches wrote:
On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote:
This work-in-progress patch generalizes the malloc/free problem-checking
in -fanalyzer so that it can work on arbitrary acquire/release API pairs.
It adds a new __attribute__((dealloca
On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote:
> This work-in-progress patch generalizes the malloc/free problem-checking
> in -fanalyzer so that it can work on arbitrary acquire/release API pairs.
>
> It adds a new __attribute__((deallocated_by(FOO))) that could be used
> like this in
On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote:
This work-in-progress patch generalizes the malloc/free problem-checking
in -fanalyzer so that it can work on arbitrary acquire/release API pairs.
It adds a new __attribute__((deallocated_by(FOO))) that could be used
like this in a library
