Hacker News Reader

Comment by kibwen | Hacker News Reader

> "As of Rust 2018, this still can cause undefined behavior."

This is referring to the fact that you have to be careful when accessing the fields of a packed struct that everything is aligned correctly. Normally anything where "you have to be careful" in order to uphold memory safety requires use of the `unsafe` keyword, but due to an oversight Rust doesn't currently require it in this instance. So, in typical Rust fashion, this isn't referring to anything sinister like a compiler miscompilation, it's just an error that Rust isn't being as paranoid as it strives to be. :P

The patch to require this `unsafe` annotation was actually just filed last week; it will become a warning first, then might become a hard error for users who opt-in to the upcoming 2021 edition: https://github.com/rust-lang/rust/pull/82525

View on HN

>> "As of Rust 2018, this still can cause undefined behavior." > > This is referring to the fact that you have to be careful when accessing the fields of a packed struct that everything is aligned correctly. Normally anything where "you have to be careful" in order to uphold memory safety requires use of the `unsafe` keyword, but due to an oversight Rust doesn't currently require it in this instance.

No, there's a huge difference between UNDEFINED BEHAVIOR and UNSAFE BEHAVIOR (in the sense of "be careful here").

Take Ada's "Unchecked_Conversion" function, it operates essentially the same as C++'s bitwise-cast, and thus is unsafe ("be careful" sense) but is not undefined.

Rust uses "unsafe" to refer specifically to memory safety, not merely for any operation considered generally undesirable. Because UB can cause any effect at all, anything that is potentially UB is regarded as "unsafe".

That is a mistake. Architectures are being updated to support unaligned access. MIPS, PowerPC, and ARM have all been updated. The machines that can't handle unaligned access are going the way of machines with sign-magnitude integers, trap representations, 9-bit bytes, base-16 floating-point, and so many other terrible things that must have seemed like good ideas at the time.

Misbehavior manifests even on x86, see the tracking https://github.com/rust-lang/rust/issues/27060 for examples. If you have more information, please leave a comment there.

Somebody already made a comment, which seems to be getting ignored:

https://github.com/rust-lang/rust/issues/27060#issuecomment-...

Basically, Intel goofed back when SSE was first introduced, and some compilers (including both gcc and llvm) got tripped up. Intel made two instructions for loading SSE registers, a normal one and one that would take alignment faults. There was the suggestion that the one with alignment faults would perform better, so people used it. In later processors, the tiny difference went away. So now you have a useless instruction supported by the hardware, and it is getting emitted by LLVM.

All the other instructions that could be emitted by llvm, and all the instructions that should be emitted by llvm, do not take alignment faults.

I don't believe they're being ignored, however, I encourage you to comment if you have something to add, even if it is just to reiterate that comment in a modern context.

Reply on news.ycombinator.com