[cfe-commits] Patch: Add warning for undefined reinterpret_cast behavior

[Chandler Carruth]

I share John and Doug's concern over false positive rates. However, I'd like
to evaluate that by getting a conservative version of this in, trying it on
some code, and evaluating the fallout. If this isn't useful we can drop it.

However, I think we could do a couple of things more to avoid
false-positives:

1) Only warn on reference reinterpret casts when the result is in an
lvalue-to-rvalue cast to avoid this false positive:

float f = 0.0f;
int *x = &reinterpret_cast<int&>(f);

2) Don't warn for reinterpret casts of tag types. The original bug this was
intended to catch were people abusing reinterpret cast to get at the bits of
a float. We can catch that without flagging type-system manipulations and
struct munging that are fairly common. This will allow us to catch the
obvious bugs surround primitive types, function pointers, etc.

John, Doug, would that alleviate some of your concerns?

On Tue, Mar 29, 2011 at 1:11 PM, Richard Trieu <rtrieu at google.com> wrote:

> Revising the patch per your suggestions:
> 1) Make this warning off by default
> 2) Removing unrelated whitespace changes
> 3) Replace underscores with hyphens in diagnostic group name
>
>
> On Sun, Mar 27, 2011 at 3:13 AM, John McCall <rjmccall at apple.com> wrote:
>
>> On Mar 27, 2011, at 2:44 AM, Douglas Gregor wrote:
>> > On Mar 22, 2011, at 10:24 PM, Richard Trieu wrote:
>> >> Add a warning for when reinterpret_cast leads to undefined behavior.
>>  Also updated reinterpret_cast tests and turned off this warning for tests
>> that don't need it.
>> >
>> > I'm not totally convinced that this warning is useful. The issue is that
>> we're not really invoking undefined behavior by performing the cast, or even
>> dereferencing the result of that cast, so long as the memory we're pointing
>> to actually has an object of the right type. However, that's not what this
>> warning is checking: this warning is checking whether the declared type
>> before the cast, and the type we're casting to, are compatible.
>> >
>> > Overall, I expect that this warning will have a fairly high
>> false-positive rate, since programmers tend to use reinterpret_cast in very
>> specific ways where they know far more about the type of the object behind
>> the pointer/reference than the type system says. To really catch problems
>> with reinterpret_cast, we're likely to need some stronger analysis (e.g.,
>> something in the static analyzer) that checks that we aren't referring to
>> the same lvalue in different places with different, incompatible types.
>>
>> This isn't just an abstract point — we use reinterpret_cast in various
>> Clang headers to convert up and down class hierarchies that we don't want to
>> require the inclusion of headers for.  In addition, while reinterpreting a
>> pointer to a double object as an int* and accessing it is technically
>> undefined behavior because of aliasing rules, it's actually such an
>> important idiom that a major design goal of the LLVM aliasing optimization
>> has been to make sure that "sufficiently obvious" code is not broken by
>> strict aliasing.
>>
>> I think that even if this warning were doing the more sophisticated
>> analysis Doug has in mind, it would still be inappropriate for it to be
>> enabled by default.
>>
>> Also, your patch has unrelated whitespace changes;  please remove these.
>>
>> John.
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110411/8bb1458c/attachment.html>