Hacker News Reader

Comment by vlovich123 | Hacker News Reader

You’ve changed the goal to something I didn’t state and then demonstrate that it’s a bad idea. I agree it’s impossible to restrict unsoundness to only appear within unsafe, but that’s not the goal.

Of course unsafe code can generate unsoundness in safe code. The main difference is that unsoundness would be more bounded somewhere between unsafe blocks as you’ve written which improves code review and the speed with with issues are found.

I’ll also note that the +=1 is also potentially unsound in release builds since Rust doesn’t do overflow checks at runtime (although since it presumably originates from a valid address that’s not possible in practice). It’s the one practical tradeoff Rust chose to make to allow UB in sounds code so that code wasn’t overly verbose while retaining good performance at runtime.

View on HN

Overflowing addition is never UB in Rust - it is defined to wrap around in release builds (i.e. it would be a compiler bug if adding 1 to 255_u8 in a release build produced any value other than 0_u8).

Sorry, was thinking of signed integer overflow which while considered sound is simultaneously considered to be a a bug in your code (hence the panic in debug mode and requires the use of wrapping_add if you intend the wrapping).

Rust behaves as you describe for both signed and unsigned.

>You’ve changed the goal to something I didn’t state and then demonstrate that it’s a bad idea.

No - I guess I should have been more clear but I don't think `unsafe` demarcates the boundary between sound and unsound. I think what happens in unsafe are things that potentially memory unsafe or thread unsafe. Pointer casts are not included in that - I feel that would only provide a false sense of safety.

Except unsafe is used more than just for memory and thread safety. Unsafe can acquire whatever semantics you want it to. It’s just that Rust the standard library and standard language has mandated that memory and thread unsoundness is always unsafe. But I can easily make an additional constraint that I annotate as unsafe and the compiler will help me enforce it (if I recall correctly the embedded guys use this when interacting with hardware even though there’s no memory or thread safety issues & I’ve seen it in other places too). It’s a fairly arbitrary choice about what’s considered safe by default vs unsafe and you can always expand the surface area of unsafe.

As for false sense of safety or not, that’s a value judgement whereas we can actually derive metrics about it (eg. build a version of the compiler that require it be annotated unsafe and then investigate now illegal call sites to count how many errors per instance there turned out to be).

It’s technically true that you can make unsafe mean whatever you want in your own projects, but redefining it to include nondeterministim that doesn’t itself result in UB would be such a fundamental change to the semantics broadly accepted by the rust community that it’s very unlikely they would do so for language constructs like `as`.

That said, I think `as` is generally a code smell and the one large professional Rust project I’ve worked on banned it in CI via clippy.

The +=1 in the above code is defined behavior. Unlike in C, the Rust compiler is not allowed to assume that overflow does not happen, and must restrict its optimizations accordingly. The undefined behavior in this code would be a result of the dereference in the next line. If there existed a check to ensure that overflow had not occurred prior to the dereference, then this code would be well-defined. And because overflow is defined behavior in Rust, the aforementioned overflow check could not be optimized away, as it could in C.

overflow of unsigned integers is well-defined in C.

You're confusing it with overflow of signed integers.

Sorry. Not UB but a likely a logical bug in the code (and a potential security exploit).

Reply on news.ycombinator.com