Re: The Case for Rust (in any system)

Personally I've started enabling Wall Wextra Wpedantic and fanalyzer in my C projects' repositories. Facing the exact same issue with fanalyzer, known as false positives, I've chosen to refactor perfectly functioning code to eliminate said false positives and avoid having legit bugs that could have been found by static analysis hidden by a backlog of magnitudes more false positives.

Would that increase development time? Yes, but does it cost more than switching to rust?

Fotis

-------- Original Message --------
On 9/6/24 10:02, David Chisnall <theraven@freebsd.org> 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. 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. 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. 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. 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).
>  
>  David
>  
>  
>