Add IPC handling for INVALID_HANDLE_VALUE on Win64 builds

ipc/ipc_message_utils.cc

 // Copyright (c) 2012 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.
 
 #include "ipc/ipc_message_utils.h"
 
 #include "base/files/file_path.h"
 #include "base/json/json_writer.h"
 #include "base/memory/scoped_ptr.h"
 #include "base/nullable_string16.h"
@@ skipping 737 matching lines @@
 }
 
 void ParamTraits<Message>::Log(const Message& p, std::string* l) {
   l->append("<IPC::Message>");
 }
 
 #if defined(OS_WIN)
 // Note that HWNDs/HANDLE/HCURSOR/HACCEL etc are always 32 bits, even on 64
 // bit systems.
 void ParamTraits<HANDLE>::Write(Message* m, const param_type& p) {
   m->WriteUInt32(reinterpret_cast<uint32>(p));

[cpu_(ooo_6.6-7.5), 2013/03/03 19:36:24]

why not do it here instead?

 }
 
 bool ParamTraits<HANDLE>::Read(const Message* m, PickleIterator* iter,
                                param_type* r) {
   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;
 }
 
 void ParamTraits<HANDLE>::Log(const param_type& p, std::string* l) {
   l->append(StringPrintf("0x%X", p));
 }
 
 void ParamTraits<LOGFONT>::Write(Message* m, const param_type& p) {
   m->WriteData(reinterpret_cast<const char*>(&p), sizeof(LOGFONT));
 }
@@ skipping 37 matching lines @@
   return result;
 }
 
 void ParamTraits<MSG>::Log(const param_type& p, std::string* l) {
   l->append("<MSG>");
 }
 
 #endif  // OS_WIN
 
 }  // namespace IPC