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

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

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

> > 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?
>
> That seems like it will have at least three flavors of false positive:
>
> 1. C's "effective type" rule allows writes to set the type pretty much unconditionally, unless the storage is for a variable with a declared type
> 2. After a placement new in C++, you should be able to use the storage as a new type
> 3. Storing directly to a member access on a union (ie, with the syntax `x.a = b`) in C++ permits using the storage as the new type
>
>   If we want to follow the relevant language rules by default, that would suggest that "writes always set the type" should be enabled by default in C and disabled by default in C++. That may not be the right decision for other reasons, though. In C++, writes through union members and new-expressions should probably (re)set the type


Fair enough. For now we'll default to write-sets-the-type as the default. We can always add 'sticky' types later to correspond to types set by declaration.

> (do you have intrinsics the frontend can use to do so?).

I had thought that we could just use a lifetime.end/start pair to mark the placement new, etc. However, it might be better to use some dedicated intrinsic for this purpose?


https://reviews.llvm.org/D32199