[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.

So, three points:

- That's not class-member-specific; you can have a placement `operator new[]` at global scope that isn't the special `void*` placement operator and therefore still has a cookie, and it would have just as much flexibility as a class-member override would.  So the split you're trying to describe is the standard operators vs. custom ones.

- Anyone can provide their own definition of the standard operators; there are some semantic restrictions on those definitions, but I'm not sure what about those restrictions would forbid this kind of capture.

- Even with the standard implementations of the standard replaceable operators, I'm not sure what rule would actually outlaw the client from going from the result of `new[]` back to the cookie.

At any rate, taking the feature as a given, the first point suggests `-fsanitize-address-poison-custom-array-cookie` or something along those lines.  If we want a more standard-ese term than "custom", the standard refers to its operators collectively as "library allocation functions", so maybe "non-library".


Repository:
  rC Clang

https://reviews.llvm.org/D52615