3 ms·

Safety has to deal with soundness, which can be related to security. They are not synonyms. Whatever you're doing, you should care about soundness. In games an

Safety has to deal with soundness, which can be related to security. They are not synonyms. Whatever you're doing, you should care about soundness. In games and HFT unsound code leads to segfaults or undefined behavior, not necessarily security issues.

logicchains 7y ago
I suppose the difference is it's much easier to get code "sound enough" through unit testing and asan/Valgrind when you know you'll never have to deal with deliberately crafted adversarial input. Whereas in a server or web browser "sound enough" is not good enough, because given enough time somebody will probably find a way to exploit any unsoundness, so the only option is to be completely sound.
- unlinked_dll 7y ago
  The advantage of rust is that you can write it soundly the first time, without a barrage of unit tests and manual (and slow!) runs through asan/valgrind memcheck. There are a handful of places where safety guarantees can (in some cases) actually cause performance issues. Most common would be iterators created from nested adapters over slices of known length. But that's the kind of thing unsafe exists for and no one is going to get fussy about you using the escape hatch for the manual checks. But most of the soundness guarantees of rust can't be avoided without a bit of effort even within unsafe blocks, and don't come with performance hits. That is because the core promise of borrow checker is that it guarantees you will not create multiple mutable aliases of the same data through your program logic (you can only really do this with manual pointer hackery, edit: or interior mutability primitives). That's what omits things like iterator invalidation and use after move/free from being composable in the language itself, and they're things that asan and valgrind can't really catch unless you're fuzzing the crap out of your program during testing. But that's a lot of effort and developer time sitting around to make a best guess about something not happening that doesn't have performance impacts. But really at the end of the day, soundness, memory safety, secure, these are correlated but different concepts that most programs have to deal with in one way or another.

logicchains 7y ago

I suppose the difference is it's much easier to get code "sound enough" through unit testing and asan/Valgrind when you know you'll never have to deal with deliberately crafted adversarial input. Whereas in a server or web browser "sound enough" is not good enough, because given enough time somebody will probably find a way to exploit any unsoundness, so the only option is to be completely sound.

unlinked_dll 7y ago
The advantage of rust is that you can write it soundly the first time, without a barrage of unit tests and manual (and slow!) runs through asan/valgrind memcheck. There are a handful of places where safety guarantees can (in some cases) actually cause performance issues. Most common would be iterators created from nested adapters over slices of known length. But that's the kind of thing unsafe exists for and no one is going to get fussy about you using the escape hatch for the manual checks. But most of the soundness guarantees of rust can't be avoided without a bit of effort even within unsafe blocks, and don't come with performance hits. That is because the core promise of borrow checker is that it guarantees you will not create multiple mutable aliases of the same data through your program logic (you can only really do this with manual pointer hackery, edit: or interior mutability primitives). That's what omits things like iterator invalidation and use after move/free from being composable in the language itself, and they're things that asan and valgrind can't really catch unless you're fuzzing the crap out of your program during testing. But that's a lot of effort and developer time sitting around to make a best guess about something not happening that doesn't have performance impacts. But really at the end of the day, soundness, memory safety, secure, these are correlated but different concepts that most programs have to deal with in one way or another.