[cfe-dev] static analyzer bug && diagnostics about suspicious casts

[Richard Smith]

On Wed, Jun 19, 2013 at 9:44 AM, John McCall <rjmccall at apple.com> wrote:
> 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>.

Also of note: the "if both T1 and T2 are standard-layout types" clause
has been removed from more recent drafts of the standard, see DR1412.