Date: Fri, 06 Sep 2024 23:22:26 +0000 From: fvalasiad <fvalasiad@proton.me> To: "theraven@freebsd.org" <theraven@freebsd.org>, "asomers@freebsd.org" <asomers@freebsd.org> Cc: "dsl@freebsd.org" <dsl@freebsd.org>, "jan@digitaldaemon.com" <jan@digitaldaemon.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: The Case for Rust (in any system) Message-ID: <eQhUKn7bKDfhBUiHYwN5FBQYjnMK7TjWlJQU3SHp_XqqeOe-7qQbOtJZeXbcjhdE8O9RZfGg8P_mvgzaLws2ZXN6eiuND0h0IXRJqNxK_Ac=@proton.me> 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
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 switc= hing 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. > =20 > In general, it=E2=80=99s very hard to add static analysis to existing pr= ojects. The property that you want is that there are no *new* static analys= er errors in a new commit, but that=E2=80=99s requires tracking all of the = existing ones. In CHERIoT RTOS, we run the clang analyser in CI as one of t= he checks that must pass before a PR can be merged. This is possible becaus= e 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 report= s and the first ten I looked at were all false positives. There are probabl= y some serious issues in there but the effort to find them is high. For a n= ew project, that cost is a small incremental cost in each commit and code r= eview (if the analyser finds something, reviewer has to agree that it= =E2=80=99s a false positive). > =20 > David > =20 > =20 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eQhUKn7bKDfhBUiHYwN5FBQYjnMK7TjWlJQU3SHp_XqqeOe-7qQbOtJZeXbcjhdE8O9RZfGg8P_mvgzaLws2ZXN6eiuND0h0IXRJqNxK_Ac=>