[PATCH] D52615: Handle -fsanitize-address-poison-class-member-array-new-cookie in the driver and propagate it to cc1

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D52615#1275946, @filcab wrote:

> In https://reviews.llvm.org/D52615#1272725, @rjmccall wrote:
>
> > In https://reviews.llvm.org/D52615#1266320, @filcab wrote:
> >
> > > In https://reviews.llvm.org/D52615#1254567, @rsmith wrote:
> > >
> > > > This seems like an unreasonably long flag name. Can you try to find a shorter name for it?
> > >
> > >
> > > `-fsanitize-poison-extra-operator-new`?
> > >  Not as explicit, but maybe ok if documented?
> >
> >
> > `-fsanitize-address-poison-array-cookie`?
>
>
> I strongly dislike this one because "poison array cookie", in general, is always enabled (it's actually triggered by a runtime flag). This flag is about poisoning it in more cases (cases where the standard doesn't completely disallow accesses to the cookie, so we have to have a flag and can't enable it all the time).


Hmm.  This naming discussion might be a proxy for another debate.  I understand the argument that programs are allowed to assume a particular C++ ABI and therefore access the array cookie.  And I can understand having an option that makes ASan stricter and disallow accessing the array cookie anyway.  But I don't understand why this analysis is in any way case-specific, and the discussion you've linked doesn't seem particularly clarifying about that point.  Can you explain this a little?

The discussion you've linked doesn't explain why this differs from case to case.  Can you please provide both a positive and a negative example of cases where there actually is an array cookie but    I don't understand the case-by-case distinction from the discussion there.  I get that the cookie

In what situations is there an actual cookie in which it is differently legal to assume information about the C++ ABI and


Repository:
  rC Clang

https://reviews.llvm.org/D52615