Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[Gavin Ray <ray.gavin97@gmail.com>]

> Unfortunately not: even fairly simple-looking C++ code can generate extra CFG
edges relating to exception-handling ... making the output essentially useless.

Ahh, I had figured the answer might be something like this. Thanks for
confirming. At least from the small codebase I have, swapping from C -> C++ when
compiling preserves all -fanalyzer warnings except for the ones from custom
malloc() attributes, so that's nice.

I won't count on the analyzer being able to do a stellar job though, so I'll
take what I can get =)

> I'm hoping to spend a good chunk of the GCC 14 development cycle working on
> adding C++ support

That's awesome! I hope you'll write some on these changes again -- I really
enjoyed reading your article on the state of Static Analysis in GCC 12 and your
LPC presentation.

I believe that's where I learned about the SARIF exporter, which with the VS
Code extension is just beyond cool!

> The analyzer makes use of the "malloc", "nonnull" and "const" function
attributes. It does make use of the "access" attribute, but only within
-Wanalyzer- tainted-size, for the case where the size param of the access is
attacker-controlled.

Ahh okay, thanks. I currently don't run the taint analysis, as this app is a
database a-la Postgres/SQLite built as a learning exercise/hobby so it's not so
much of a concern.

> the first [[gnu::malloc]] here is redundant, as it's implied by
> [[gnu::malloc(HeapPage_free, 1)]].

Good to know, ty -- it may be useful to modify the 'attribute' docs for these,
because currently it shows combined usage and phrases it as:

"Independently, the form of the attribute with one or two arguments associates
deallocator as a suitable deallocation function..."

__attribute__ ((malloc, malloc (fclose, 1))) FILE* fdopen (int, const char*);

On a related note, the "fd" analyzers warn: "fd may not be valid" but don't
clarify what "valid" means.

I found the DOT diagrams in the analyzer source and it turns out that the key is
to check "if (fd >= 0)". Maybe this could be added to the "fd" analyzer
warnings/info, too?

====================

Anyways, sorry to drone on. I think that the GCC Static Analyzer and the LLVM
Dataflow Analysis Framework are vital for the the evolution of safety and
developer experience in authoring C/C++

Big thanks to all involved and it's exciting to watch the shortlog & follow the
progress from the sidelines =)