Re: [boost] [optional] Strict Aliasing Warnings on Trunk

Subject: Re: [boost] [optional] Strict Aliasing Warnings on Trunk
From: Bo Persson (bop_at_[hidden])
Date: 2009-12-17 16:10:17

Giovanni Piero Deretta wrote:
> On Thu, Dec 17, 2009 at 5:51 PM, Bo Persson <bop_at_[hidden]> wrote:
>> Mathias Gaunard wrote:
>>> Dean Michael Berris wrote:
>>>> I've recently been seeing this error more and more especially on
>>>> GCC with -Wall: /home/dean/boost/boost/optional/optional.hpp:407:
>>>> warning:
>>>> dereferencing pointer ‘<anonymous>’ does break strict-aliasing
>>>> rules /home/dean/boost/boost/optional/optional.hpp:427: note:
>>>> initialized from here and:
>>>>
>>>> /home/dean/boost/boost/function/function_base.hpp:321: warning:
>>>> dereferencing type-punned pointer will break strict-aliasing
>>>> rules /home/dean/boost/boost/function/function_base.hpp:325:
>>>> warning: dereferencing type-punned pointer will break
>>>> strict-aliasing rules
>>>>
>>>> This is on Linux and GCC 4.4.1.
>>>>
>>>> I'm not an expert in this regard but is there a way to either
>>>> silence or avoid these warnings? Anything you want me to try from
>>>> my end?
>>>
>>> This was discussed in the past, and some people claimed the
>>> warning was spurious.
>>>
>>> I am personally not convinced whether it is spurious or not,
>>> however.
>>
>> Using a reinterpret_cast to convert from one pointer type to an
>> unrelated type seems to conflict with the rules at the end of
>> chapter 3 of the standard.
>
> the conversion itself does not conflict with the standard. It is the
> dereferencing of the pointer that migh...
>
>>
>> "If a program attempts to access the stored value of an object
>> through an lvalue of other than one of the following
>> types the behavior is undefined: ..."
>>
> [this list include accessing an object with a type different from
> its dynamic type]
>
> ... but the dynamic type of the internal buffer of boost::optional
> has been changed via placement new, so (modulo compiler bugs) it
> should be safe: at any time the buffer has a specific type (when
> initialized) or no type at all (it is just a bunch of memory).
> Boost optional only dereferences the buffer when it has been
> initialized, and always with the same type used for placement new.
> Of course this is hard (impossible?) to prove statically and gcc
> warns even if it should be perfectly safe .
>

But how do we know that the warning is just in case, and that the 
compiler isn't really confused?

Or some other compiler that doesn't understand enough to even issue a 
warning?

Bo Persson