Re: [lmi] Working with and around strict aliasing

[Vadim Zeitlin]

On Sun, 20 Sep 2015 18:01:13 +0000 Greg Chicares <address@hidden> wrote:

GC> > I think it describes exactly what the function does and
GC> > is much more specific than the two latter variants above which seem to
GC> > imply that they can convert between arbitrary types and not just convert
GC> > from "char*"
GC> 
GC> I was strongly tempted to change that to "unsigned char*", to guard
GC> against trap representations, but exquisite refinements can wait.

 FWIW I agree that it would be better to use "unsigned char" here.

GC> I even resisted, for now, the urge to add a static assertion that the
GC> type converted to is a POD.

 This is something that I thought about doing but finally didn't just
because it's something that would be so much simpler in C++11 that I
decided it wasn't worth trying to do this in C++98. You'll note that I
optimistically assume I will be able to update this code after switching to
C++11 during my life-time.

GC> But I did change this, in 'soa_helpers.hpp':
GC> 
GC> -        rec.index = *reinterpret_cast<boost::int32_t*>(index_record);
GC> +        rec.index = deserialize_cast<boost::int32_t>(index_record);
GC> 
GC> because of an extremely similar change in 'actuarial_table.cpp':
GC> 
GC>         int index_table_number =
GC> -            *reinterpret_cast<boost::int32_t*>(index_record)
GC> +            deserialize_cast<boost::int32_t>(index_record)
GC> 
GC> figuring that if either is problematic, then both are. The question,
GC> if I'm not missing something, is whether or not dereferencing this:
GC>   reinterpret_cast<boost::int32_t*>(index_record)
GC> comes under the shadow of the strict-aliasing prohibition, and I
GC> suppose it's an accident that g++ diagnosed one but not the other.

 Yes, sorry for missing this, this definitely looks like it breaks the
strict aliasing rules and I have no idea why didn't g++ warn me about it.

 Thanks for noticing this!
VZ