[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114217

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i at maskray dot me

--- Comment #14 from Fangrui Song <i at maskray dot me> ---
I agree with Jakub and Andrew.

The relevant rules: C11 6.3.2.3 says

> An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.
>
> A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. ...

C++ [expr.static.cast]p14 says of conversions from a misaligned pointer:

> A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T”, where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. If the original pointer value represents the address A of a byte in memory and A does not satisfy the alignment requirement of T, then the resulting pointer value is unspecified. ...

Which is allowed to be an invalid pointer value, which the compiler is then
permitted to give whatever semantics we like, such as disallowing it being
passed to memcpy.

---

memcpy is preferred for expressing an unaligned access.

typedef struct dir_entry dir_entry_u __attribute__((aligned(1)));
// In C++, there is an alternative: using dir_entry_u
__attribute__((aligned(1))) = dir_entry;

u64 gu(dir_entry_u *entry)
{
    return entry->offset;
}