On Wed, 2022-11-23 at 20:49 -0500, Gavin Ray via Gcc wrote: > Hey all, just a few questions about the fantastic GCC Static > Analyzer:
Hi! > > - It's stated that support for C++ vs C is very limited. Does this > apply if > you're writing C++ that is very similar-looking to C and uses few > of C++'s > advanced features? Unfortunately not: even fairly simple-looking C++ code can generate extra CFG edges relating to exception-handling, which -fanalyzer currently doesn't understand at all, making the output essentially useless. And that's just one issue... Strictly speaking I have added some *very* minimal regression tests in C++ to our test suite, but on anything beyond the most trivial example it's likely to run into a known issue. I'm tracking some of these known issues here: https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110 but the C++ support is currently so minimal that it's probably not yet worth filing extra bugs against that tracker :-/ I'm hoping to spend a good chunk of the GCC 14 development cycle working on adding C++ support, with the aim of being able to analyze GCC itself ("eating my own dog food"), so I hope this situation will improve greatly then. > > - I noticed that in C++, the "gnu::malloc" attributes don't seem to > report > "warning: leak of 'xxx_alloc()' [CWE-401] [-Wanalyzer-malloc- > leak]", is > this > normal? In theory they should; but you could be running into issues with the analyzer not fully understanding the control flow graph. > > - Is it worthwhile to spend time annotating your method signatures > with > attributes like "malloc" and "access"? Do these aid the -fanalyzer > passes? 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 (and the taint checker is currently off by default, even with -fanalyzer). But like I said, don't expect these to work on C++ code yet. > > For instance: > > [[gnu::malloc]] [[gnu::malloc(HeapPage_free, 1)]] IIRC, the first [[gnu::malloc]] here is redundant, as it's implied by [[gnu::malloc(HeapPage_free, 1)]]. > [[gnu::returns_nonnull]] > struct HeapPage* HeapPage_alloc(); > > [[gnu::access(read_write, 1, 3)]] > struct RecordID > HeapPage_insert_record(struct HeapPage* page, const char* record, > uint32_t record_length); > > That's quite a significant bit of annotation-noise tacked on to the > function, so > I wanted to be sure it's worth the investment! Maybe in GCC 14 onwards, but it definitely won't be worth it at the moment. Hope this is helpful Dave > > Thank you =) > Gavin Ray >
