What exactly does unsound mean in context of Rust?

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:

2 Likes

This is probably the best explanation I've seen: https://docs.rs/dtolnay/0.0.7/dtolnay/macro._03__soundness_bugs.html

8 Likes

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"

3 Likes

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?

2 Likes

I like the /dev/random approach! :metal:

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>.

1 Like

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.

5 Likes

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.

2 Likes

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.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.