History: In systems programming, Rust must interoperate with C and other languages requiring predictable memory layouts. Early Rust allowed aggressive compiler optimizations including arbitrary field reordering to minimize padding and cache misses, whereas C mandates declaration-order field layout. This dichotomy necessitated explicit representation attributes to guarantee stability for FFI boundaries.
Problem: The repr(Rust) default grants the compiler freedom to reorder struct fields, insert padding, and optimize niche values, meaning the binary representation is unspecified and may vary between compiler versions. Conversely, repr(C) imposes a stable, C-compatible layout with deterministic field offsets. Transmuting raw bytes (e.g., from network packets or C libraries) into repr(Rust) structs violates Rust's memory model because the actual field offsets may not match the source data, leading to load of invalid values or unaligned accesses.
Solution: Explicitly annotate structs intended for FFI or raw memory mapping with #[repr(C)] to freeze field order and alignment. For pure Rust code where layout flexibility is acceptable, repr(Rust) remains the default. When serialization is required without FFI, prefer safe deserialization libraries rather than mem::transmute, as even repr(C) does not guarantee absence of padding bytes or platform-specific alignment.
#[repr(C)] struct PacketHeader { flags: u8, length: u16, // Compiler cannot swap with flags }
Context: While developing a high-performance network intrusion detection system, I needed to parse Ethernet frame headers directly from a mmap'd packet ring buffer. The system targeted both x86_64 servers and embedded ARM64 devices.
Problem: The initial implementation used a repr(Rust) struct to represent the Ethernet header (destination MAC, source MAC, ethertype). When attempting to transmute the raw byte slice into this struct for zero-copy parsing, sporadic crashes occurred on ARM64 but not x86_64, indicating undefined behavior.
Solution 1: Naive transmutation with repr(Rust). I considered simply casting the pointer with mem::transmute or std::slice::from_raw_parts, relying on the struct definition matching the wire format. Pros: Zero overhead, no copying. Cons: repr(Rust) allows the compiler to reorder the ethertype field before the MAC addresses to optimize alignment, causing the transmuted struct to interpret MAC bytes as the ethertype and vice versa. This is immediate undefined behavior and platform-specific.
Solution 2: Explicit #[repr(C)] annotation. Adding #[repr(C)] forces the compiler to maintain declaration order, matching the IEEE 802.3 standard layout exactly. Pros: Predictable offsets, safe for FFI and raw memory mapping. Cons: Potential performance cost due to suboptimal padding (the compiler cannot reorder fields to minimize size), resulting in slightly larger structs and potential cache inefficiency.
Solution 3: Manual byte parsing (bytemuck or manual indexing). Using the bytemuck crate with Pod traits or manually slicing bytes with u16::from_be_bytes. Pros: Fully safe, no unsafe blocks, handles alignment correctly. Cons: Runtime overhead of byte-swapping for endianness and field-by-field copying, complicating the code.
Chosen solution: I selected Solution 2 (#[repr(C)]) combined with #[derive(Copy, Clone)] and explicit padding fields to match the 14-byte header size exactly. The minor cache inefficiency was acceptable because the NIC driver already aligned packets to cache lines, and correctness was paramount for security auditing.
Result: The parser stabilized across x86_64 and ARM64. It passed Miri validation for strict provenance checking. Finally, it successfully integrated with the libpcap FFI layer without crashes or data corruption.
Why does adding explicit padding fields to a repr(C) struct sometimes change the ABI compatibility with C code, and how does #[repr(C, packed)] alter this risk?
Adding explicit padding (e.g., _: u16) to match a C header assumes the C compiler uses the same alignment rules. However, Rust and C may differ on bitfield packing or alignment of arrays. #[repr(C, packed)] removes all padding, forcing fields to align to byte boundaries. Pros: Matches packed C structs exactly. Cons: Unaligned field access becomes undefined behavior in Rust unless done through read_unaligned; the compiler cannot optimize unaligned reads, and on some architectures (ARM, RISC-V), this triggers hardware exceptions. Candidates often miss that packed shifts the safety burden entirely to the programmer.
How does the validity invariant of a bool differ between repr(Rust) and repr(C), and why does this affect transmuting u8 to bool?
Rust's bool has a strict validity invariant: it must be 0x00 (false) or 0x01 (true). C typically treats any non-zero value as true. When transmuting a u8 from C into a repr(C) struct containing bool, if the C code set the byte to 0x02, Rust immediate undefined behavior occurs, even with repr(C). repr(Rust) vs repr(C) does not change the bool validity invariant—Rust always requires 0 or 1. Candidates often assume repr(C) relaxes Rust's type invariants; it only affects layout, not validity. The solution is to use u8 in the struct and convert via != 0 in safe code.
Can you legally transmute a &[u8] slice into a &[ReprCStruct] reference, and what alignment constraints must be verified beyond mere size?
Transmuting slices is not direct; one must use align_to or pointer casting. The critical missed constraint is alignment: the u8 slice may have alignment 1, while ReprCStruct might require alignment 4 or 8. Creating a reference to an under-aligned value is immediate undefined behavior. Candidates often check size_of but forget align_of. The solution uses std::slice::from_raw_parts only after verifying ptr.align_offset(std::mem::align_of::<T>()) == 0, or copying to an aligned buffer. Miri will flag this as Undefined Behavior if alignment is violated.