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:
>>>> 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,
>> 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