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

[James Y Knight via llvm-dev]

On Thu, Jan 14, 2016 at 10:59 PM, John McCall via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> Part of my point is indeed an acknowledgement that valid objects can exist
> at misaligned addresses, and it should not be UB to perform a member access
> into them as long as the memory isn't accessed.  Consider, say, a pointer
> serialized data structure held in an unaligned buffer.  I am trying to say
> that code which drills into that data structure via that pointer and then
> works around the lack of alignment on the resulting address is not buggy;
> you seem to be suggesting that it is, and that the user has a
> responsibility to ensure that all of their pointer arithmetic is done on
> properly-aligned pointers.  I don’t think that's a defensible model.
>
> (Note that sometimes the only way we detect the UB stemming from member
> access on a non-object -- for instance, with UBSan -- is because the
> pointer is misaligned. Your list can be read as suggesting that the UBSan
> alignment check for member access would violate our guarantees.)
>
>
> That’s true; I do not think the UBSan alignment check should be kicking in
> when we’re not accessing memory.
>

Arithmetic (e.g. +), and casts is one thing. But, you're actually
*dereferencing* a pointer which isn't valid (granted the dereference is
syntactic, and doesn't result in an actual load.) I don't understand why
you think it is not a defensible model to (continue to) forbid this?

Furthermore, if that is to be valid, why should it only be the case for
misalignment, and not null?

That is, I'd argue that either "&X->foo" should be considered always valid,
regardless of what the value of the X pointer is, OR it must (as it does
now) require an X pointing to an actually valid object. Going halfway and
saying it's only valid for some kinds of invalid X pointers does not seem
like a good way to go.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160115/433a8fba/attachment.html>