Add IPC handling for INVALID_HANDLE_VALUE on Win64 builds

ipc/ipc_message_utils.cc

Index: ipc/ipc_message_utils.cc
===================================================================
--- ipc/ipc_message_utils.cc	(revision 185796)
+++ ipc/ipc_message_utils.cc	(working copy)
@@ -763,7 +763,11 @@
   uint32 temp;
   if (!m->ReadUInt32(iter, &temp))
     return false;
-  *r = reinterpret_cast<HANDLE>(temp);
+  // On Win64 all HANDLE values are 32-bits except for INVALID_HANDLE_VALUE.
+  if (reinterpret_cast<uint32>(INVALID_HANDLE_VALUE) == temp)

[piman, 2013/03/03 16:50:18]

why not simply reading and writing the data of the correct size?

[jschuh, 2013/03/03 17:15:05]

32-bits is the correct size because valid handles are required to fit in the
lower 32-bits, so you can pass them between 64-bit and 32-bit processes.   The
only quirk is that INVALID_HANDLE_VALUE is a sentinel value that's not really
intended to be passed between processes. However, our architecture relies on it,
so it makes sense for us to special case it and handle the conversion ourselves.

[piman, 2013/03/03 17:31:38]

Do we use IPC between 32 and 64 bit processes? Do we even have mixed bit-ness
processes?

It sounds like could have a bunch of other problems when we pass around data
structures, that end up having different sizes or packed differently.

[jschuh, 2013/03/03 17:41:24]

Absolutely. We have it today with NaCl, and off the top of my head we know we'll
have it with the 32-bit plugin container and possibly with the Firefox profile
importer.
Well, packed structures at the IPC layer are pure evil and should really not be
allowed for many other reasons. That said, the cases where we need to
communicate from 64-bit to 32-bit are narrow enough that it won't be a big
concern.

+    *r = INVALID_HANDLE_VALUE;
+  else
+    *r = reinterpret_cast<HANDLE>(temp);
   return true;
 }