Compare bugs found with ASan/UBSan/TSan + testing / fuzzing vs. static analysis. Static analysis barely finds anything. It also tends to have lots of false positives, which are harmful, and encourage making changes to the code which can and often does lead to introducing bugs.
Conversation
The Debian key generation issue is a particularly well known example, but there are lots of others. Lots of projects have had bad experiences with it. Here's one: sqlite.org/testing.html#s.
2
1
"Static analysis has found a few bugs in SQLite, but those are the exceptions. More bugs have been introduced into SQLite while trying to get it to compile without warnings than have been found by static analysis."
1
1
It's like that for Linux kernel as well. There are classes of bugs that defy casual static analysis and you have to basically make your own runtime correctness checking tools (lockdep etc)
1
1
This Tweet was deleted by the Tweet author. Learn more
Choosing safe architectures and tools is obviously part of good design. Those design choices made before starting to write any code for the implementation are some of the most important. Static analysis can be quite helpful, but depends a lot on the language making it work well.
1
1
Static analysis doesn't work well for C, due to the lack of memory safety and very weak type system. It's very difficult to accurately analyze. It loses far more of the intent behind the design than a safer language and/or one with features for writing more structured code.
1
This Tweet was deleted by the Tweet author. Learn more
There's literally hundreds of research papers on the subject from which Rust was based on -- and now many are written about Rust.
Languages have to be designed around static code analysis from the beginning. There are many language concepts that make reliable analysis possible.
This Tweet was deleted by the Tweet author. Learn more
There was already a thread in response elaborating on it:
Quote Tweet
Replying to @vyodaiken @billhuey and 5 others
I haven't made any statements that resemble "it seems plausible to me". You keep taking the approach of attacking me and misrepresenting what I've been saying.
The statements I made about static analysis and self-explanatory. It works better when code has stronger guarantees.
This thread touches on the difference between weak / incomplete heuristics and enforcing meaningful safety guarantees:
twitter.com/DanielMicay/st
It uses an example that's easy to solve (uninitialized memory) rather than just heuristics catching some issues with false positives.
Quote Tweet
Replying to @DanielMicay @pcwalton and 7 others
There's a big distinction between weak warnings / static analysis and doing it properly. For example, GCC / Clang will warn for things like possibly uninitialized variables. However, they don't implement a system for guaranteeing that C code has no uninitialized variable use.
2
1
Pretty big difference between adding weak heuristics to catch a subset of bugs with false positives and actually coming up with rules to fix a clear subset if the issue or the whole issue. The more open ended static analysis also works way better with stronger guarantees.
1
This Tweet was deleted by the Tweet author. Learn more
I explained it an easily understandable way. I don't need an argument from authority for something that can be explained quickly.