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.

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/

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 <cottrell(a)wfu.edu&gt; > 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/ >> [1] > > > Links: > ------ > [1] > https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/ > > _______________________________________________ > 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/ _______________________________________________ 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/