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(a)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(a)gretlml.univpm.it
To unsubscribe send an email to gretl-devel-leave(a)gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/