[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D32199#731332, @rsmith wrote:

> > ! In https://reviews.llvm.org/D32199#731252, @hfinkel wrote:
> > 
> >> How about renaming this to something more like `-fsanitize=type`?
> > 
> > I'm fine with that. Do you like TypeSanitizer or TypeAccessSantizer or TypeAliasingSanitizer best?
>
> I think calling it a type aliasing sanitizer would somewhat conflate the details of the mechanism with the fundamentals of the check itself. For example:
>
>   variant<int, float> v;
>   int &n = v.get<int>;
>   v = 1.3f;
>   int m = n;
>
>
> ... is a lifetime bug, not an aliasing bug, but would be caught by this check just the same.


Good point.

>   I'd be tempted to suggest EffectiveTypeSanitizer, since we seem to be more-or-less directly implementing C's effective type rules, except that name isn't so good for the C++ case. And in the longer term we will probably want to provide an option to enforce the real C++ lifetime rules whereby a store with certain !tbaa metadata is not sufficient to change the type of storage.

As I've currently implemented it, both reads and writes set the type of previously-unknown storage, and after that it says fixed (unless you memcpy to it, memset it, or its lifetime ends (the type gets reset on lifetime.start/end and for malloc/allocas/etc.). There's a flag to enable the "writes always set the type" rule, but that's not the default. Is this too strict?

> 
> 
>> One potential concern with calling it the type sanitizer is that we have an abbreviation overlap with the thread sanitizer.
> 
> Perhaps we could abbreviate it as "tysan"? *shrug*

SGTM.


https://reviews.llvm.org/D32199