This is an archive of the discontinued LLVM Phabricator instance.

[ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't available
ClosedPublic

Authored by vsk on Jul 31 2017, 1:43 PM.

Details

Summary

In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I did not see the need for the two checks to have separate null checking logic for the same pointer. I expected the two checks to either always be enabled together, or to be mutually compatible.

In the mailing list discussion re: r309007 it became clear that that isn't the case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean, it's useful to have -fsanitize=vptr emit its own null check. That's what this patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.

Diff Detail

Repository
rL LLVM

Event Timeline

arphaman edited edge metadata.Aug 2 2017, 4:08 AM

That makes sense. It's kinda weird not to report the null, but I guess it makes sense if the null sanitiser is off. It's not actually UB unless it's dereferenced, right, so casts are allowed?

test/CodeGenCXX/ubsan-type-checks.cpp
73 ↗(On Diff #108988)

Can you use reuse the first invalid_cast with different checks since the code is the same?

vsk marked an inline comment as done.Aug 2 2017, 11:00 AM

That makes sense. It's kinda weird not to report the null, but I guess it makes sense if the null sanitiser is off.

It is kinda weird, but any such diagnostic would fit better under -fsanitize=null, and that's explicitly not enabled.

It's not actually UB unless it's dereferenced, right, so casts are allowed?

Right, even the null sanitizer doesn't issue reports when it finds an {up,down}cast of null.

@arphaman thanks for taking a look! I've fixed the test case issue you pointed out and added minor comment and doc updates. I'll go ahead and commit to unblock Nico.

This revision was automatically updated to reflect the committed changes.