A bug story: data alignment on x86

Post by GlitchMr » Mon, Nov 07, 2016, 5:56 PM UTC

Sagiri wrote: post #38

ogoffart wrote: post #33

Again someone who relies on undefined behavior. Casting pointer of wrong alignement is not a platform specific behavior, it's an undefined behavior. Relying on it is an error. The author did not know "What Every C Programmer Should Know About Undefined Behavior": http://blog.llvm.org/2011/05/what-every-c-programmer-should-... Another good link about that: http://blog.regehr.org/archives/213

If a particular compiler specified that casting pointers of wrong alignments causes a segfault, it'd be perfectly acceptable to rely on that behavior. The standard would consider it UB, but that compiler has defined that behavior sufficiently. Note, though, that a compiler simply doing a particular thing now isn't good enough to specify it in the sense that I mean. The compiler writers would have to explain (in a blo…

Post by Jweb_Guru » Mon, Nov 07, 2016, 5:59 PM UTC

GlitchMr wrote: post #52

Sagiri wrote: post #38

Earlier quoted context omitted.

If a particular compiler specified that casting pointers of wrong alignments causes a segfault, it'd be perfectly acceptable to rely on that behavior. The standard would consider it UB, but that compiler has defined that behavior sufficiently. Note, though, that a compiler simply doing a particular thing now isn't good enough to specify it in the sense that I mean. The compiler writers would have to explain (in a blo…

The thing is, many compilers just assume that undefined behaviour won't happen, without defining any particular behaviour. And testing for something like pointer alignment on architectures that silently allow pointer misalignment is really, really expensive. That said, you can use -fsanitize=undefined to verify correctness of a program (as far specification is concerned). Just be prepared for it being a bit slow.

Post by to3m » Mon, Nov 07, 2016, 6:27 PM UTC

Someone wrote: post #55

Sagiri wrote: post #38

Earlier quoted context omitted.

If a particular compiler specified that casting pointers of wrong alignments causes a segfault, it'd be perfectly acceptable to rely on that behavior. The standard would consider it UB, but that compiler has defined that behavior sufficiently. Note, though, that a compiler simply doing a particular thing now isn't good enough to specify it in the sense that I mean. The compiler writers would have to explain (in a blo…

Technically, if a compiler specifies how it handles undefined behavior (as opposed to implementation-defined behavior, which it must define), it stops being a C compiler :-) I also think it is fairly unlikely that any C compiler will say anything about how it handles undefined behaviour because it would mean it has to generate awfully inefficient code. For example, a compiler could not optimize away most pointer dere…

Post by Thiez » Mon, Nov 07, 2016, 6:49 PM UTC

steveklabnik wrote: post #23

alkonaut wrote: post #19

Earlier quoted context omitted.

Not sure if this is what you are asking: Last time I tried alignment in Rust I worked around the lack of explicit alignment support by adding a zero length array of the correct size to the end of the struct. Not sure if alignment support from proper attributes has landed yet. [repr(C)] struct Something { pub foo: f32, pub _alignment: [EightBytes, 0] } where "EightBytes" is a data type of size 8, to align the whole st…

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:: ()); assert_eq!(2, std::mem::size_of:: ()); assert_eq!(4, std::mem::size_of:: ()); assert_eq!(4, std::mem::size_of:: ()); }

Post by [deleted] » Mon, Nov 07, 2016, 6:55 PM UTC

Someone wrote: post #55

Sagiri wrote: post #38

Earlier quoted context omitted.

If a particular compiler specified that casting pointers of wrong alignments causes a segfault, it'd be perfectly acceptable to rely on that behavior. The standard would consider it UB, but that compiler has defined that behavior sufficiently. Note, though, that a compiler simply doing a particular thing now isn't good enough to specify it in the sense that I mean. The compiler writers would have to explain (in a blo…

Technically, if a compiler specifies how it handles undefined behavior (as opposed to implementation-defined behavior, which it must define), it stops being a C compiler :-) I also think it is fairly unlikely that any C compiler will say anything about how it handles undefined behaviour because it would mean it has to generate awfully inefficient code. For example, a compiler could not optimize away most pointer dere…