Hacker News Reader

Comment by nemothekid | Hacker News Reader

>I agree with the author that casting between unrelated pointer types should probably be considered unsafe but would probably require a new edition which would mean Rust 2027 at the earliest

As I understand it, unsafe pretty much says "what you are doing here may violate memory safety". Casting doesn't do that, only dereferencing. If you'd like to increase the scope to also include "things that might violate memory safety for another code block", then shouldn't compile either:

    let mut foo = unsafe { int_ref as *const u32 as usize };
    foo = foo + 1;
    let bar = unsafe {*(foo as *const u32)}

the mutation of foo is also "unsafe" under this definition, and the compiler shouldn't let you modify pointers in any manner.

View on HN

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.

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.

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.

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

overflow of unsigned integers is well-defined in C.

You're confusing it with overflow of signed integers.

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

> As I understand it, unsafe pretty much says "what you are doing here may violate memory safety".

I don't think this is true in general. Unsafe is used pretty frequently for things that are themselves memory safe but may violate invariants which can cause memory unsoundness in other places. An example would be `std::str::from_utf8_unchecked` which is not itself memory unsafe. But various safe methods on `str` are memory safe ONLY if the str contains valid UTF8

Reply on news.ycombinator.com