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

[Pavel Labath]

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.

But I guess you're right. I think I'll abandon this warning idea.

the alignment requirements of T2 are no stricter than those of T1, or if
> either type is void. Converting a prvalue of type “pointer to T1” to the
> type “pointer to T2” (where T1 and T2 are object types and where the
> alignment requirements of T2 are no stricter than those of T1) and back to
> its original type yields the original pointer value. The result of any
> other such pointer conversion is unspecified.
>
> John.


regards,
pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130619/2fcc9f8a/attachment.html>