[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)
Daniel Berlin via cfe-commits
cfe-commits at lists.llvm.org
Mon May 1 15:40:07 PDT 2017
On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 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>
>>> 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 to be clear, i mean given:
struct b bstruct;
given a pointer to bstruct, subtracting sizeof(int) is not going to give
you a pointer to a struct a.
It was allowed to work for vtable accesses.
everyone else got told to turn off strict aliasing if you wanted it to
work, and they did.
But again, i'll go thread spleunking
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits