kcc added a comment.
> Maybe we could call this `-fpoison-dangling-ptrs` and force users to be more > explicit about opting into this behavior change. That would remove some of > the constraints usually placed on new sanitizer checks (e.g support for > executing after the error triggers, support for custom trap functions). What's wrong with -fsanitize=SOMETHING? (the exact value of SOMETHING is debatable) >> @kcc Is it safe to add a handler for segv and continue program execution as >> normal? I'm asking because I haven't tried that before, and am guessing you >> have experience with this from working on asan. Not sure I understand your question. We can add an optional SEGV handler to ubsan that will see the address on which we failed, and say something like "faulty address is close to 0xDEADBEEF, use of dangling pointer suspected. <STACK_TRACE>" Then exit. >> One more thing to consider: how will we support >> -fsanitize-trap=value-after-delete? This will essentially only have the trap mode, it will not support -fsanitize-recover > Sanitizers.def:105 > + Null | ObjectSize | Return | ReturnsNonnullAttribute | > Shift | > + SignedIntegerOverflow | ValueAfterDelete | VLABound | > + Unreachable | Function | Vptr) Agree with Peter's concern -- it may break rare valid cases, so it should not be in this group. We already have unsigned-integer-overflow that will also break valid code, so it's fine to have a second case like that. https://reviews.llvm.org/D25199 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
