Live data from Hacker News

Prusti: Static Analyzer for Rust

github.com

11–20 of 93 posts

Re: Prusti: Static Analyzer for Rust

#11

Why would you need a static analyzer for a language that promotes itself as safe out of the box.

> safe out of the box

Safe Rust is memory safe and data race safe. There are other forms of safety obviously, like overflow safety, numerous forms of confidentiality and security properties, etc.

Re: Prusti: Static Analyzer for Rust

#12
That looks incredibly useful. Proving the absence of panics and overflows is already great, and with the annotations you can guarantee properties you'd normally write property tests for, like in this example from the docs:

  impl List {
      #[ensures(self.len() == old(self.len()) + 1)]
      pub fn push(&mut self, elem: i32) {
          // TODO
      }
  }

Re: Prusti: Static Analyzer for Rust

#13
post #2

What are people's experiences with static analyzers at companies? Many people I have spoken with have either never heard of them, or expressed no interest. Usually those same people use dynamic languages like Ruby or Python.

In the typical enterprise projects I work on they are quite typical, usually we tend to use stuff like SonarQube and it breaks the build for specific errors.

Usually it doesn't matter if devs themselves don't care, because when devops have the management support, they will care to fix that broken build.

Re: Prusti: Static Analyzer for Rust

#14
post #2

What are people's experiences with static analyzers at companies? Many people I have spoken with have either never heard of them, or expressed no interest. Usually those same people use dynamic languages like Ruby or Python.

When I worked on a big c++ codebase I found them essential for both ci/cd systems and actively debugging an issue. The valgrind suite of tools like cachegrind are very useful for both troubleshooting as well as classic static analysis and I heartily recommend investing some time in learning valgrind if you're writing c/c++ code for a platform valgrind runs on.

On the other hand commercial tools have been more of a mixed blessing but that is probably because every time ive seen them deployed the budget hasnt included sufficient engineering time, training or prof services to cut down huge numbers of false positives.

Re: Prusti: Static Analyzer for Rust

#16
post #15

Why would you need a static analyzer for a language that promotes itself as safe out of the box.

It is safe for the 70% of security flaws found out in languages like C and C++. The remaining 30% still need to be tracked down.

I wonder where you got those numbers from.

Re: Prusti: Static Analyzer for Rust

#17
post #16
post #15

Earlier quoted context omitted.

It is safe for the 70% of security flaws found out in languages like C and C++. The remaining 30% still need to be tracked down.

I wonder where you got those numbers from.

A report about Windows written by Microsoft, I think.

Re: Prusti: Static Analyzer for Rust

#18
post #2

What are people's experiences with static analyzers at companies? Many people I have spoken with have either never heard of them, or expressed no interest. Usually those same people use dynamic languages like Ruby or Python.

I can't even convince my co-workers to use Typescript. :-/

I think it varies by industry though.

Re: Prusti: Static Analyzer for Rust

#19
post #2

What are people's experiences with static analyzers at companies? Many people I have spoken with have either never heard of them, or expressed no interest. Usually those same people use dynamic languages like Ruby or Python.

Big tech uses static analyzers a lot. See for example, these projects: - https://fbinfer.com/ ( - https://github.com/google/error-prone - https://github.com/facebook/SPARTA And many others

Many of Google's general checks in clang-tidy should be directly available, too. For example, the absl checks seem to be on the list of clang-tidy checks:

https://clang.llvm.org/extra/clang-tidy/checks/list.html

Re: Prusti: Static Analyzer for Rust

#20
post #16
post #15

Earlier quoted context omitted.

It is safe for the 70% of security flaws found out in languages like C and C++. The remaining 30% still need to be tracked down.

I wonder where you got those numbers from.

Almost every study of security vulnerabilities concludes that roughly 70% of them are caused by memory unsafety.
Post reply on HN