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/ >
_______________________________________________ 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/
