[llvm-dev] [cfe-dev] RFC: Enforcing pointer type alignment in Clang

[David Chisnall via llvm-dev]

Hi John,

On 15 Jan 2016, at 08:14, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> The question at hand is whether we should require the user to write this:
>   misaligned_A_B *p = &a.b;
> instead of, say:
>   A::B *p = &a.b;
>   int x = *(misaligned_int*) &p->n;
> because we want to reserve the right to invoke undefined behavior and propagate our “knowledge" that p is 4-byte-aligned to “improve” the 1-byte-aligned access on the next line.
> 
> My contention is that this is a clean and elegantly simple formal model that is disastrously bad for actual users because it is no longer possible to locally work around a mis-alignment bug without tracking the entire history of the pointer.  It is the sort of compiler policy that gets people to roll their eyes and ask for new options called things like -fno-strict-type-alignment which gradually get adopted by 90% of projects.

I’ve had the misfortune to look at a lot of code that does unaligned access over the last few years.  By far the most common reason for it that I’ve seen is networking code that uses packed structures to represent packets.  For example:

__attribute__((packed))
struct somePacket
{
	uint8_t a;
	uint32_t b;
	// ...
};

In your model, what happens when:

- I use field b directly?
- I take the address of field b and store it in an int* variable?

David