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

[Daniel Berlin via cfe-commits]

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

> On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>> 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>
>>>> 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 to be clear, i mean given:
>>
>> struct a
>> {
>> int a;
>>  struct b bstruct;
>> };
>>
>> given a pointer to bstruct, subtracting sizeof(int)  is not going to give
>> you a pointer to a struct a.
>>
>
> If sizeof(int) happens to equal offsetof(struct a, bstruct), it sure
> should (if you're doing the pointer arithmetic on an appropriate type, of
> course).
>
>



> It was allowed to work for vtable accesses.
>>
>
> I would like to once again remind you that random mailing list
> conversations you happened to be in but can't even remember from some
> completely unnamed
>

It's not unnamed, it's either gcc@, gcc-patches@ or gcc bugzilla.
I can even give you approximate dates if you like.

I don't believe calling "the other major compiler's mailing list", which
treaded exactly this topic, is "a random mailing list conversation", or "an
unnamed source" or a "different context".


> and possibly different context are neither authoritative nor binding on us
> now. :)
>
> John, while i appreciate the smiley, this is kind of rude.
Without a good reason to be different, we should follow the paths other
compilers have taken and users have become used to. Both in what we allow,
and what we disallow.
So if the plan here is go off and do something that is going to be
completely different than what users expect from their compilers, that
doesn't make a lot of sense to me.
Otherwise, if you really don't want me to tell you what they've done, and
try to explain why, okay, fine, then i'll bow out of these discussion and
leave y'all to do whatever.

Just don't expect me to okay patches to llvm that implement the current
kind of hacks we currently have.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170501/1282fefe/attachment-0001.html>