Date: Fri, 6 Sep 2024 08:02:28 +0100 From: David Chisnall <theraven@freebsd.org> To: Alan Somers <asomers@freebsd.org> Cc: Dmitry Salychev <dsl@freebsd.org>, Jan Knepper <jan@digitaldaemon.com>, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <6FEF9D06-01DC-48DC-93D2-178F9726C1D3@freebsd.org> In-Reply-To: <CAOtMX2j=EA5XLQ6jG3_XRyLd7QPj4j-nKKoCMdiYA7QoMNmQZg@mail.gmail.com> References: <CAOtMX2j=EA5XLQ6jG3_XRyLd7QPj4j-nKKoCMdiYA7QoMNmQZg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Sep 2024, at 22:13, Alan Somers <asomers@freebsd.org> wrote: >=20 > 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=E2=80=99s very hard to add static analysis to existing projec= ts. The property that you want is that there are no *new* static analyser er= rors in a new commit, but that=E2=80=99s requires tracking all of the existi= ng ones. In CHERIoT RTOS, we run the clang analyser in CI as one of the chec= ks that must pass before a PR can be merged. This is possible because we sta= rted 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 f= irst ten I looked at were all false positives. There are probably some serio= us issues in there but the effort to find them is high. For a new project, t= hat cost is a small incremental cost in each commit and code review (if the a= nalyser finds something, reviewer has to agree that it=E2=80=99s a false pos= itive). David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6FEF9D06-01DC-48DC-93D2-178F9726C1D3>