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