[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 2:07 PM, John McCall <rjmccall at gmail.com> wrote:

> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>> So you believe that you can index into an object randomly by pointer
>>>> arithmetic and pull out a different field?
>>>>
>>>
>>> For starters, this is  illegal because you don't know where the padding
>>> bytes are.
>>> You cannot assume that X.a + 1 == X.b
>>> "Implementation alignment requirements might cause two adjacent members
>>> not to be allocated immediately after each other;"
>>>
>>> See 9.2.14
>>>
>>
>> IE at best you'd have to add
>>
>>  &(struct X*(0))->b - &(struct X*(0))->a
>>
>>
>> I don't believe this is legal either.
>>
>> Let me try to dredge up the long discussions we had about these cases on
>> the gcc mailing lists.
>> The conclusion was, i believe:
>>
>> "if you want to go marching through an object as a char *, that's fine,
>> if you expect to be able to get at fields by playing pointer arithmetic
>> games, from other fields, that is not)
>> I feel like every couple years, a different compiler has the same
>> aliasing discussions :)
>>
>
> With the caveat that, in practice, compilers have to support both:
>   a) "going up a level" by subtracting an offsetof, which is clearly
> officially intended and not otherwise supported,
>

AFAIK, Vtable accesses were supported by doing this, but pretty much
nothing else.



> and
>   b) treating a final or flexible array member, possibly at depth > 1, as
> contiguous with a trailing array, because this is an extremely common
> extension and artificial idiom.
>

Yes, anything at the end was treated as magically special.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170501/8292c763/attachment-0001.html>