On Fri, Dec 18, 2009 at 4:11 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Dec 17, 2009 at 11:17 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
Really? I thought this was implementation-defined?
Sure, but it is specified that if you reinterpret_cast from T1* to T2*, then reinterpret_cast the resulting T2* back to T1*, you'll get the original value (as long as T2 doesn't have stricter alignment requirements.)
See, the strict alignment requirements are what the compiler is warning about -- saying that it *may* break as a diagnostic is how it does it. Because the issue raised has already been pointed out to be a bug in that it's almost indiscriminate that even legitimate constructs do get flagged as potentially breaking strict aliasing rules, I'd say reinterpret_cast<> aside, the strict aliasing warnings do have merit in situations that they may cause problems at runtime. It's not *only* in cases that you have reinterpret_cast that it warns -- heck, it can even warn for using C-style casts and not only in C++, but even in C mode.
Reinterpret_cast is tricky but it is part of the language and it's lame for the compiler to warn when it is used.
Which warning are you pointing at? The strict aliasing warnings? Again, it's not only in cases where you have reinterpret_cast that it warns, it also happens in cases where you do cast the types of the pointers and try to dereference these type-punned or casted pointers. What *is* lame is how after years of references and legitimate safe pointer operations not involving reinterpret_cast, we're still having a discussion about it -- reinterpret_cast. ;) -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com