Comment by ajxs | Hacker News Reader

Comment by ajxs | Hacker News Reader

Parent Full thread

Regarding `repr(packed)`: Thank you for posting this. I really like Rust's official documentation on the subject. I stand corrected regarding Rust's support of structure packing. The following statement is a little troubling however: "As of Rust 2018, this still can cause undefined behavior." This greatly affects Rust's suitability for bare-metal programming, where you very often require control over a structure's layout in memory at bit-level granularity.

Regarding bitfields: At the risk of sounding a little old-fashioned, I don't like the idea of having to import external packages to provide these kinds of fundamental features. The article hints as much. It might be a bit of a culture clash however I feel that learning the different styles and interfaces of a bunch of external packages is an extra, undesirable cognitive burden imposed on the developer. Plus, "A macro to generate structures which behave like bitflags" (The crate's official description) doesn't sound very robust to me. It sounds like precisely the kind of hack that a future release could break.

In fairness, it should be mentioned that the C standard does not guarantee the layout and order of individual bitfields either (refer to section 6.7.2.1 paragraph 11 of the C1X standard). Even though the usage of bitfields is common in C, it's not without its issues.

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

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.

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

Reply on news.ycombinator.com