Giovanni Piero Deretta wrote:
On Thu, Dec 17, 2009 at 5:51 PM, Bo Persson <bop@gmb.dk> 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