Hi Hélio,
Thanks for your initiative. We have a repo on sourceforge with Allin's
and some additional (assertion) tests mainly I wrote.
I also have the plan to mirror the SF repo frequently on github, and
execute some container running the test suit in case of changes in the
source code. I guess it makes sense if we discuss that before. What do
you think?
Best,
Artur
Am 24.08.2021 21:37 schrieb Hélio Guilherme:
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 <cottr...@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-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
[1]
Links:
------
[1]
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
_______________________________________________
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
_______________________________________________
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
