title: Valid uses cases for reinterpret_cast for unaligned memory access vs memcpy?
body: <p>In the internals of snappy, there is a conditionally compiled section that selects <a href="https://code.google.com/p/snappy/source/browse/trunk/snappy-stubs-internal.h?r=62#101" rel="noreferrer">dereferencing a reinterpret_cast'ed</a> pointer as the best implementation for reads and writes of potentially unaligned 16, 32, and 64 bit integers on architectures that are known to support such operations (like x86). The fallback for other architectures is to use a <a href="https://code.google.com/p/snappy/source/browse/trunk/snappy-stubs-internal.h?r=62#154" rel="noreferrer">memcpy based implementation</a>.</p>
  
  <p>My understanding is that the reinterpret_cast implementation exhibits undefined behavior, and clang's undefined behavior sanitizer does flag it.</p>
  
  <p>What is puzzling me though is: why not just use the memcpy based implementation? I would expect all but the most broken of compilers to use intrinsics to implement these memcpy calls, since the size is known at compile time. In fact I would expect identical codegen from both implementations on any modern toolchain.</p>
  
  <p>However, I also recognize that snappy was written by folks who know what they are about. So this leaves me wondering whether there is still some advantage to using the reinterpret_cast mechanism that outweighs its being undefined behavior. Not wanting performance to depend on compiler quality of implementation? Something else I haven't considered?</p>