I am glad that it is a useful tool.

I agree that the Rules are more focused for newer C lang specification, and code styles (but it is still a good exercise).

We can adjust the Rules (but it is easier to ignore them).

On next analisis we will see the improvements Allin did.

I have more plans for this GitHub clone. I have already a branch with the tests Alling provided, and in the future, whenever I update the branch they will run.

More things could come for automation, like producing .rpm and .deb packages (like snapshots, for Linux).

Hélio

On Tue, Aug 24, 2021 at 7:21 PM Allin Cottrell <cottrell@wfu.edu> wrote:

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_______________________________________________
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-leave@gretlml.univpm.it
Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/