This revision was automatically updated to reflect the committed changes.
Closed by commit rL309846: [ubsan] Have -fsanitize=vptr emit a null check if
-fsanitize=null isn't… (authored by vedantk).
Changed prior to commit:
https://reviews.llvm.org/D36112?vs=108988&id=109385#toc
Repository:
rL
vsk marked an inline comment as done.
vsk added a comment.
In https://reviews.llvm.org/D36112#828891, @arphaman wrote:
> 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 fi
arphaman added a comment.
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?
Comment at: test/CodeGenCXX/ubsan-type-checks.cpp:73
+
Alex is in a different time zone, so he may not get to this today.
Do you have the time to give a review?
> On Aug 1, 2017, at 12:38 PM, Nico Weber wrote:
>
> It'd be good if this could go in today. ubsanvptr has been broken for us for
> a while now.
>
> On Mon, Jul 31, 2017 at 4:43 PM, Vedan
It'd be good if this could go in today. ubsanvptr has been broken for us
for a while now.
On Mon, Jul 31, 2017 at 4:43 PM, Vedant Kumar via Phabricator via
cfe-commits wrote:
> vsk created this revision.
>
> In r309007, I made -fsanitize=null a hard prerequisite for
> -fsanitize=vptr. I did not
vsk created this revision.
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 compatibl