Date: Wed, 11 Sep 2024 05:54:55 +0000 From: Paul Floyd <paulf2718@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <efe9562c-b16a-4e2f-b3ed-820e2d138283@gmail.com> In-Reply-To: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> References: <CAOtMX2j=EA5XLQ6jG3_XRyLd7QPj4j-nKKoCMdiYA7QoMNmQZg@mail.gmail.com> <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06-09-24 07: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. 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). Beware of the confimation bias false positives as well, where the tool is correct but the developer wants to believe that their code is correct. The main problem with static analysis is complexity. As I understand it they only perform analysis at function scope. Since the output is explained step by step you can usually see why it went wrong. One common thing that I see is that in one place it reports a size to be within a certain range and then later reports an out of bounds access with a different size. Because of its vision of local scope it doesn't see that the size can't change between the two (assuming monothrededness). A+ Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?efe9562c-b16a-4e2f-b3ed-820e2d138283>