Conversation

"Rust doesn't check integer overflow" is one of the worst reasons I've ever heard to avoid it in favor of a non-memory-safe language. You can turn on Rust integer overflow checks with a compiler flag. You can't turn on memory safety in non-memory-safe languages.

351

Replying to

You could argue that compiling with asan is turning on memory safety. Sort of.

Replying to

and

Not at all since the only issues it finds reliably are linear overflows. It can't detect temporal safety issues when allocations are out of the quarantine and can't detect most out-of-bounds accesses but rather only special cases. It can't detect anything within objects either.

Replying to

and

Sure they aren’t the same but not that different either. The tools available for “memory unsafe” languages (like asan, valgrind) catch the vast majority of memory bugs. Acting like it’s the wild wild west for C/C++ is silly.

Replying to

and

They detect memory corruption when it occurs at runtime not the presence of the memory corruption bugs. If the current usage of the program doesn't trigger memory corruption with those bugs, there's nothing for them to detect. They're far from detecting the vast majority of them.

5:05 PM · Mar 30, 2022Twitter Web App

Replying to

and

In almost any mature program, the vast majority of memory corruption bugs will be latent issues not actually corrupting memory between objects during regular usage. ASan only detects memory corruption when it occurs, only between objects (not within) and nowhere close to all.

Replying to

and

ASan can detect a substantial subset of non-adversarial memory corruption between objects. That's so far from being even a significant percentage of the latent memory corruption bugs in any program. If that was anywhere close to true, software would be dramatically more secure.

Show replies