[anextio]

Replying to your other comment.

> You are claiming that static code analysis tools extensively used in C++ cannot detect all conceivable and hypothetical memory issues. The weasel words in here is that it is possible to detect them, but some can conceivably slip through.

No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem.

> To drive the point home, there are already a few CVEs even from use-after-free bugs in Rust code. What does that make out of the all assertion? Would this be a reasonable argument to reject Rust as an unsafe language?

The CVE that you referenced in the other comment was Rust calling into unsafe C code, as I pointed out. If you have a real example feel free to post it.

> The problem with these claims is that they rely on weak strawmen arguments and a very superficial analysis of the problem space. I get the need to do marketing, but if the audience is technical them don't you think arguments should stand on solid technical ground?

The views I have laid out here are the consensus among compiler engineers and in theoretical computer science. You only have to look at the compiler group at Apple:

- heavily invested in static analysis - maintains the clang static analyzer - maintains number of runtime memory analysis tools in Xcode - not invested in rust at all and seemingly not interested

Yet they are adding lifetime dependency annotations to Swift, making it more like Rust: https://github.com/swiftlang/swift-evolution/blob/ef71df4158...

The reason for this is that static analysis simply cannot do it when the semantic information about lifetimes is lost, even for a group that knows how to write strong static analysis tools. Program flow is too ambiguous without it, so it becomes impossible to detect such memory vulnerabilities without running the program and fuzzing it – an expensive, time consuming, and probabilistic process.

[motorest]

> No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem.

This is the sort of goalpost-moving that lays bare how superficial and misleading these accusations are. You're trying to argue that some very specific types of memory vulnerabilities can't be detected with static code analysis tools. That is different than claiming that it's not possible to detect memory vulnerabilities in languages such as C or C++, isn't it? But somehow this strawman is used to imply that Rust is invulnerable whereas developers using any other language are prevented from ever learning that standard FLOSS compilers support out of the box things such as detecting use of uninitialized variables.

So what is it then?