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

base/bit_cast.h

Index: base/bit_cast.h
diff --git a/base/bit_cast.h b/base/bit_cast.h
new file mode 100644
index 0000000000000000000000000000000000000000..ae28d19cbdca8e6834906306b3ce181b213574a4
--- /dev/null
+++ b/base/bit_cast.h
@@ -0,0 +1,74 @@
+// Copyright 2015 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.
+
+// 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 ISO C++ specification section 3.10 -15 -.  Roughly, this

[Avi (use Gerrit), 2015/12/30 16:57:37]

"-15 -"?

Perhaps:

"according to the ISO C++98 specification, section 3.10 ("basic.lval"),
paragraph 15. (This did not substantially change in C++11.)"

[tapted, 2016/01/03 23:51:06]

Done.

+// 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 3.10 -15- is to allow optimizing compilers to assume

[Avi (use Gerrit), 2015/12/30 16:57:37]

"-15-" again?

"The purpose of this paragraph..."

[tapted, 2016/01/03 23:51:06]

Done.

+// that expressions with different types refer to different memory.  gcc
+// 4.0.1 has an optimizer that takes advantage of this.  So a

[Avi (use Gerrit), 2015/12/30 16:57:37]

GCC 4.0.1 was released in 2005. Do we want to keep this reference or just
vagueify the paragraph a bit as "this is the right thing to do"?

[tapted, 2016/01/03 23:51:06]

I went with "Compilers are known to take advantage of this." (i.e. to keep the
message that bit_cast exists because of known problems rather than merely an
interpretation of the standard)

aside: Interestingly... Chrome compiles with -fno-strict-aliasing which turns
off these kinds of optimizations (as well as turning off the warnings that
dereferencing a "type punned" variable can lead to bad codegen when the compiler
assumes it isn't creating an alias for data of a different type...). 

+// 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, with a
+// constant size, gcc 2.95.3, gcc 4.0.1, and msvc 7.1 produce inline
+// code with the minimal amount of data movement.  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.
+//
+// I tested this code with gcc 2.95.3, gcc 4.0.1, icc 8.1, and msvc 7.1.

[Avi (use Gerrit), 2015/12/30 16:57:37]

More references to incredibly obsolete compilers :(

[tapted, 2016/01/03 23:51:06]

I think what's happening anyway is not that memcpy is fast, but that compilers
can replace calls to the memcpy function with inline code when the `size`
argument is a compile-time constant....  (and compilers can't make aliasing
assumptions after passing an address to a function, so there's effectively an
optimization barrier at every bit_cast).

Replaced this and the above para with

// 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.

+//
+// WARNING: if Dest or Source is a non-POD type, the result of the memcpy
+// is likely to surprise you.

[Avi (use Gerrit), 2015/12/30 16:57:37]

We should totally rewrite this template using the std::is_pod type trait so it
won't compile in this case.

[tapted, 2016/01/03 23:51:06]

Done.

+
+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");

[Avi (use Gerrit), 2015/12/30 17:32:43]

Actually, just insert two lines:

static_assert(std::is_pod<Source>::value, "Source must be a POD type");
static_assert(std::is_pod<Dest>::value, "Source must be a POD type");

with

#include <type_traits>

[tapted, 2016/01/03 23:51:06]

Done.

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