News for hackers. Stuff that matters.
Re:A bug story: data alignment on x86 by steveklabnik on Monday November 07, 2016 @09:34AM (#12891240)
Structs already insert padding to give them alignment:

    struct One {
      foo: u8,
    }
    
    struct Two {
      bar: u16,
    }
    
    struct Three {
      foo: u8,
      bar: u16,
    }
    
    struct Four {
      foo: u16,
      bar: u16,
    }
    
    fn main() {
        assert_eq!(1, std::mem::size_of::<One>());
        assert_eq!(2, std::mem::size_of::<Two>());
        assert_eq!(4, std::mem::size_of::<Three>());
        assert_eq!(4, std::mem::size_of::<Four>());
    }
Re:A bug story: data alignment on x86 by alkonaut on Monday November 07, 2016 @09:43AM (#12891325)
What I needed to do was to place e.g. a N byte struct exactly on an M byte alignment (e.g. 11 byte struct on 32 byte alignment etc).
Re:A bug story: data alignment on x86 by steveklabnik on Monday November 07, 2016 @10:10AM (#12891616)
Ah! Yeah, that's different, and as far as I know your way is the current right way to do it, but I'm not an expert on the subject.
Re:A bug story: data alignment on x86 by Thiez on Monday November 07, 2016 @01:49PM (#12893699)
Well given that Rust leaves struct layout undefined unless #[repr(C)] is specified, std::mem::size_of::<Three> is actually not guaranteed to be 4.
Re:A bug story: data alignment on x86 by steveklabnik on Monday November 07, 2016 @02:01PM (#12893824)
While this is true, it's a weird angle that's not itself super well defined. That is, the definition of repr(packed) implies that the alignment will always be there without it...