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@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/
>> [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-leave@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-leave@gretlml.univpm.it
Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/