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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
