The word "unsound" is oft quoted in relation to Rust and it's literature[1]. How is it different from, say, a bug (logical or design) or a security vulnerability?
[1] Some examples:
The word "unsound" is oft quoted in relation to Rust and it's literature[1]. How is it different from, say, a bug (logical or design) or a security vulnerability?
[1] Some examples:
Thanks for sharing that link.
So would it be correct to summarize unsoundness as: An implementation detail which allows for potential use of an abstraction in such a way that it could lead to a security or safety vulnerabilities under certain circumstances but in itself it does not represent one?
Good read indeed! Thanks for sharing!
That sounds correct, but overly complicated. I'm trying to figure out if I leaves anything uncovered though.
Regardless: I wouldn't use the words "implementation detail", because soundness is not a detail, it's a fundamental, and critical, aspect of the design, just like "correctness".
I understand you mean the jargon-version of "detail" that means "the way it is implemented, which could be changed", but that downplays the importance, and ignores the fact that some APIs can be unsound in their public interface, which is not a concealed "implementation detail" in the normal sense.
E.g. the original, unsound, API for scoped threads, which caused a bit of a (professionally-handled) meltdown when it was discovered at the time.
I've always thought about "unsound" as abstraction is built in a way that could be abused, either accidentally or intentionally (but isn't necessarily (yet))
Or, more jokingly: "unsoundness means not being resistant to an infinite number of typewriter monkeys"
Unsound code, or code that touches UB condition on runtime, is a contract violation between the programmer and the compiler. The compiler optimize the code based on this contract, and it can generate incorrect code on UB-touching branch to speed up the normal code. If you don't mind the compiler to generate incorrect code, why use compiler when the /dev/random
can also generate incorrect code but a lot faster?
I like the /dev/random
approach!
Manager: Need new system for VoIP operations ASAP.
Me:
echo `head -c 1024 /dev/urandom` | mail -s "PFA requested system" manager
Manager: Great turn-around! Ready to ship?
Me: Have doubts if it's sound.
Manager: What's the work around?
Me: Let's name it Option<Sound>
.
The dtolnay post linked above is the best choice for succinctly yet persuasively and completely explaining the healthy Rust-y attitude to take towards unsafe
code,
but
For getting a quick and punchy but still accurate dictionary definition of "unsound", I'd point at the UCG glossary: https://github.com/rust-lang/unsafe-code-guidelines/blob/636d140ce9c74ffc4d1fc082bef0771f238f64c9/reference/src/glossary.md#soundness-of-code--of-a-library
we say that a library (or an individual function) is sound if it is impossible for safe code to cause Undefined Behavior using its public API. Conversely, the library/function is unsound if safe code can cause Undefined Behavior.
Unsound means there's a loophole or an edge case that breaks safety or correctness guarantees.
When something is sound, it handles 100% of cases 100% of the time. If it handles only 99% cases correctly, it may still be safe enough in practice, but it's not sound.
I like that we can describe code as "safe and sound", this appeals to my English language sensitivities.
On the flip side we could say code is "unsafe, but sound" if the invariants are limited, correct and demonstrably upheld with 100% of inputs. This is of course much more difficult to claim and shouldn't be claimed lightly. Some might even argue it's technically impossible but I don't think that's helpful when some of Rust's implementation depends on unsafe, but sound code.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.