Conversation

Patrick Walton
@pcwalton
"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.
12
351
Daniel Micay
@DanielMicay
Replying to
@ajmmertens
and
@pcwalton
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.
2
5
Sander Mertens 🏳️‍🌈
@ajmmertens
Replying to
@DanielMicay
and
@pcwalton
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.
1
Daniel Micay
@DanielMicay
Replying to
@ajmmertens
and
@pcwalton
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.
1
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
@ajmmertens
and
@pcwalton
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.
2
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
@ajmmertens
and
@pcwalton
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.
1