Re: The Case for Rust (in any system)

On 9/6/24 03:02, David Chisnall wrote:
> On 5 Sep 2024, at 22:13, Alan Somers<asomers@freebsd.org>  wrote:
>> I used to check it, years ago.  But I gave up.  The UI is too hard to
>> use and false alarms are both too frequent and too hard to suppress.
>> Plus, it's a real drag that I can't run the tool myself.  Instead, I
>> need to wait for the next scheduled run.
> In general, it’s very hard to add static analysis to existing projects.
Not the experience I have.
It was as simple as wrapping the build with 'cov-<something>'.
(Also, Coverity would come and visit us, and assist with setting up and 
getting analyzes started).
>   The property that you want is that there are no *new* static analyser errors in a new commit, but that’s requires tracking all of the existing ones.
Coverity, when we used it did keep track of all the issues:
A false positive, when marked as false, would not be reported again.
A true positive, thus an actual problem, most (all!) of the time would 
disappear after the code was fixed and Coverity was run again.

Every analyzer I have ever used gives false positives.
VeraCode was one of the worst.
Coverity was one of the best.
(But times have changed)
>   In CHERIoT RTOS, we run the clang analyser in CI as one of the checks that must pass before a PR can be merged. This is possible because we started doing it very early on.
Good! :-)
>   It may be possible for some individual parts of FreeBSD, but when we started with Coverity I looked at the reports and the first ten I looked at were all false positives.
That can happen. I think when we first started with Coverity the false 
positives where just less then 50%. Which is truly extremely good for an 
analyzer. Then Coverity was tuned/reconfigured a bit and it became much 
better.
>   There are probably some serious issues in there but the effort to find them is high. For a new project, that cost is a small incremental cost in each commit and code review (if the analyser finds something, reviewer has to agree that it’s a false positive).
>
Well, the cost is high on an existing project alike FreeBSD, because 
this has not been done... My guess is... It could be considered 
'Technical Debt'.
What helps quite a bit is tuning Coverity to the right configuration, so 
the false positives are not overwhelming. Then, when the true positives 
are resolved, dial the tuning back a little.

Jan