Move bit_cast from base/macros.h to its own header

base/bit_cast.h

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef BASE_BIT_CAST_H_
+#define BASE_BIT_CAST_H_
+
+#include <string.h>  // For memcpy.
+
+#include <type_traits>
+
+// bit_cast<Dest,Source> is a template function that implements the equivalent
+// of "*reinterpret_cast<Dest*>(&source)".  We need this in very low-level
+// functions like the protobuf library and fast math support.
+//
+//   float f = 3.14159265358979;
+//   int i = bit_cast<int32_t>(f);
+//   // i = 0x40490fdb
+//
+// The classical address-casting method is:
+//
+//   // WRONG
+//   float f = 3.14159265358979;            // WRONG
+//   int i = * reinterpret_cast<int*>(&f);  // WRONG
+//
+// The address-casting method actually produces undefined behavior according to
+// the ISO C++98 specification, section 3.10 ("basic.lval"), paragraph 15.
+// (This did not substantially change in C++11.)  Roughly, this section says: if
+// an object in memory has one type, and a program accesses it with a different
+// type, then the result is undefined behavior for most values of "different
+// type".
+//
+// This is true for any cast syntax, either *(int*)&f or
+// *reinterpret_cast<int*>(&f).  And it is particularly true for conversions
+// between integral lvalues and floating-point lvalues.
+//
+// The purpose of this paragraph is to allow optimizing compilers to assume that
+// expressions with different types refer to different memory.  Compilers are
+// known to take advantage of this.  So a non-conforming program quietly
+// produces wildly incorrect output.
+//
+// The problem is not the use of reinterpret_cast.  The problem is type punning:
+// holding an object in memory of one type and reading its bits back using a
+// different type.
+//
+// The C++ standard is more subtle and complex than this, but that is the basic
+// idea.
+//
+// Anyways ...
+//
+// bit_cast<> calls memcpy() which is blessed by the standard, especially by the
+// example in section 3.9 .  Also, of course, bit_cast<> wraps up the nasty
+// logic in one place.
+//
+// Fortunately memcpy() is very fast.  In optimized mode, compilers replace
+// calls to memcpy() with inline object code when the size argument is a
+// compile-time constant.  On a 32-bit system, memcpy(d,s,4) compiles to one
+// load and one store, and memcpy(d,s,8) compiles to two loads and two stores.
+//
+// Note: Dest and Source must be POD types.
+//
+template <class Dest, class Source>
+inline Dest bit_cast(const Source& source) {
+  static_assert(sizeof(Dest) == sizeof(Source),
+                "bit_cast requires source and destination to be the same size");
+  static_assert(std::is_trivially_copyable<Source>::value,
+                "Source must be a POD type or trivially copyable");
+  static_assert(std::is_trivially_copyable<Dest>::value,
+                "Dest must be a POD type or trivially copyable");

[Avi (use Gerrit), 2016/01/04 00:24:46]

This is indeed a better choice than is_pod.

[tapted, 2016/01/04 00:59:30]

Doh - bots are still reporting in, but it looks like there was some lag in
compilers/libraries providing is_trivially_copyable. gcc only provides it in
libstdc++ since version 5. But some failures are on clang -- it looks like there
are bot configurations compiling with clang, but using gcc's libstdc++ from 4.x
(which surprises me - I'll try to figure out whether this is a proper
configuration).

There might be a workaround like

#if (__has_feature(is_trivially_copyable) && defined(_LIBCPP_VERSION)) ||      \
    (defined(__GNUC__) && __GNUC__ >= 5)
#define IS_TRIVIALLY_COPYABLE(T) std::is_trivially_copyable<T>::value;
#elif __has_feature(is_trivially_copyable)
#define IS_TRIVIALLY_COPYABLE(T) __is_trivially_copyable(T);
#else
#error "Can't define IS_TRIVIALLY_COPYABLE"
#endif

But I need to deploy some test CLs. Also this looks a little gross -- it might
be better to put off adding the static_assert for now, or just guarding the
asserts with _LIBCPP_VERSION, since it's likely at least one of the bots will be
compiling with libc++, so they will still be effective in picking up mistakes.

+
+  Dest dest;
+  memcpy(&dest, &source, sizeof(dest));
+  return dest;
+}
+
+#endif  // BASE_BIT_CAST_H_