filcab added a comment. In https://reviews.llvm.org/D52615#1278000, @rjmccall wrote:
> 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". Thank you. I went with your suggestion, as I think it's close enough to be understandable. I've also changed the -cc1 argument in this patch, as it looks weird to have two different arguments (unless needed). Let me know if you'd like to keep the different names. Thank you, Filipe 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
