[libcxx-commits] [PATCH] D82627: Fix CFI issues in <future>

Evgenii Stepanov via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Jul 17 09:31:54 PDT 2020


eugenis added a comment.

In D82627#2158393 <https://reviews.llvm.org/D82627#2158393>, @ldionne wrote:

> >> Before the lifetime of an object has started but after the storage which the object will occupy has been allocated [...] any pointer that represents the address of the storage location where the object will be or was located may be used but only in limited ways. [...] 
> >>  The program has undefined behavior if:
> >>  [...]
> >> 
> >> - the pointer is used as the operand of a static_cast (8.2.9), except when the conversion is to pointer to cv void, or to pointer to cv void and subsequently to pointer to cv char, cv unsigned char, or cv std::byte (21.2.1),[...]
>
> That's a good find. However, in this case, what we do is not a `static_cast`. It's a C-style cast from an unrelated type (`std::aligned_storage<...>::type`) to `__base*` (for example in the expression `(__base*)&__buf_`), which is actually equivalent to a `reinterpret_cast` unless I'm mistaken. Do you agree?


You are right. CFI also checks reinterpret_casts even if they are not UB, because they are just as likely to be a source of type confusion bugs. So, the choice here is between this change, and _LIBCPP_NO_CFI attribute. The attribute change would ideally move the casts into a helper function to avoid suppressing too much checking.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82627/new/

https://reviews.llvm.org/D82627





More information about the libcxx-commits mailing list