[cfe-dev] static analyzer bug && diagnostics about suspicious casts
John McCall
rjmccall at apple.com
Wed Jun 19 09:44:48 PDT 2013
On Jun 19, 2013, at 1:45 AM, Pavel Labath <labath at google.com> wrote:
> On 19 June 2013 01:59, John McCall <rjmccall at apple.com> wrote:
> There's nothing wrong with reinterpret_cast'ing to an arbitrary object pointer type; it doesn't need to be standard-layout. You just have to be careful to not (1) increase the alignment requirements (which we should already warn about with -Wcast-align) or (2) do anything with the type-punned pointer except cast it back eventually (which is pretty hard to reason about).
>
> And there are known encapsulation idioms which involve temporarily punning a pointer as a pointer to an incomplete type, so I'm not sure this is a terribly valuable warning to pursue even for your specific case.
>
> Obligatory standards quote:
>
> C++11 [expr.reinterpret.cast]p7:
> An object pointer can be explicitly converted to an object pointer of a different type. When a prvalue v of type “pointer to T1” is converted to the type “pointer to cv T2”, the result is static_cast<cv T2*>(static_cast<cv void*>(v)) if both T1 and T2 are standard-layout types (3.9) and
> I've read this paragraph before writing, and this part made me believe that the types need to be standard layout. I'm not very good at standardese, so I wasn't sure if this restriction applies to the following sentences or not.
It doesn't; it's a separate rule. The structure is basically: "If <A>, the result is <B>. If <C>, the result is <D>. The result of anything else is unspecified." It seems weird only because <A> is a subset of <C>.
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130619/96e763d0/attachment.html>
More information about the cfe-dev
mailing list