Boost logo

Boost :

Subject: Re: [boost] [optional] Strict Aliasing Warnings on Trunk
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-12-17 13:07:28


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 .

HTH,

-- 
gpd

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk