[OpenBIOS] Strict aliasing
Segher Boessenkool
segher at kernel.crashing.org
Wed Aug 12 15:47:12 CEST 2009
> The reason OpenBIOS violates the strict aliasing rules so often is
> because it uses char arrays to represent endian-specific data.
No. The reason it isn't valid C code is simply "because it isn't
valid C code". Specifically, it is accessing arrays of chars as
another type. This is not allowed.
> Char arrays may have alignment different from that of the longer
> types.
That is not a problem on most architectures. GCC allows it in most
(all?)
cases.
> That's why casting a pointer to such array to a pointer to a longer
> type
> and dereferencing it is considered unsafe by the compiler.
It isn't considered "unsafe". It is simply _not valid code_. It is
impossible for a compiler to detect (or diagnose!) all invalid code;
but the compiler is allowed to assume it is presented with valid code,
it can do <whatever> with invalid code.
> The compiler
> assumes that different types would not occupy the same memory
> unless we
> tell it not to make such assumption.
It's not an assumption, it is guaranteed (by definition) that in any
valid C program, any object is only accessed as its stored type or a
character type.
> Char arrays serve as protection against misusing endian-specific
> data as
> host-endian integers. The alternative it to use sparse annotated
> types,
> such as __le32. __le32 has the same alignment as u32, but sparse
> would
> recognize attempts to use __le32 in arithmetic operations.
A much better way is to access all data that needs marshalling via some
functions that do just that, e.g., read32be(const u8 *) and write16le
(u8 *, u8) .
It is much more readable, and the compiler knows what you're doing,
because it is correct C code.
Segher
More information about the OpenBIOS
mailing list