On Tue, 24 Aug 2021, Riccardo (Jack) Lucchetti wrote:
On Tue, 24 Aug 2021, Sven Schreiber wrote:
> Thanks, Hélio, this is potentially very useful. Artur came up with a
> similar (I think) automated analysis in the past, and a few code
> improvements resulted from that.
>
> OTOH, I'm sure that the true number of flaws and bugs is nowhere near
> the astronomical number reported there. I'd say the artificial
> intelligence there is not mature enough yet and the result needs more
> filtering. But I'm especially curious about the assessment of what they
> call potential security flaws.
I gave it a brief look. From a quick and non-systematic spot-check, it would
seem that many traditional C idioms are marked as potentially dangerous, but
from what I've seen we're OK.
I've been looking through the list of 1.2K bugs. It's a mixed bag.
Several hundred "bugs" are in the HTML files -- use of tags that are
deprecated in HTML 5 and the like. Among the ones in the C code,
some are very useful catches and many are plain wrong.
Things that the diagnostic is good at catching include:
* Left- and right-hand operands identical in use of logical
operators, as in "if (na(dx) || na(dx))", which is obviously a typo
but might never be spotted by the human eye.
* Repeated conditions within if/else if/else if... constructions:
only the first one would ever be triggered; subsequent ones may well
be the result of half-baked copy-and-paste.
* Possible use-after-free of allocated objects.
* Possible failure to release allocated memory.
I've fixed some of these already.
Things the diagnostic is pretty poor at:
* Diagnosis of null-pointer dereference. This _would_ be very useful
but for the fact that the majority are false positives.
* The same goes for reading off the end of arrays: some instances
may be right but many false positives.
Allin