Fix new[]/delete mismatches in sandbox handle code by switching to scoped_ptr<C, base::FreeDeleter>.

sandbox/win/src/handle_closer.cc

Index: sandbox/win/src/handle_closer.cc
diff --git a/sandbox/win/src/handle_closer.cc b/sandbox/win/src/handle_closer.cc
index a47bf6564cfc78ef9ecfb0d9fe0c96fdfe10d1d0..3d0214fee49701f20c1a85ea22a8c793bc4ad08e 100644
--- a/sandbox/win/src/handle_closer.cc
+++ b/sandbox/win/src/handle_closer.cc
@@ -1,4 +1,4 @@
-// Copyright (c) 2011 The Chromium Authors. All rights reserved.
+// Copyright (c) 2013 The Chromium Authors. All rights reserved.

[rvargas (doing something else), 2013/06/05 22:27:36]

We should not update the year on CR headers.

[Derek Bruening, 2013/06/06 04:33:25]

Hmm, yes, this is in http://www.chromium.org/developers/coding-style.  Time to
disable emacs copyright-update for Cr editing.

 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
@@ -180,11 +180,12 @@ bool GetHandleName(HANDLE handle, string16* handle_name) {
     ResolveNTFunctionPtr("NtQueryObject", &QueryObject);
 
   ULONG size = MAX_PATH;
-  scoped_ptr<UNICODE_STRING> name;
+  scoped_ptr<UNICODE_STRING, base::FreeDeleter> name;
   NTSTATUS result;
 
   do {
-    name.reset(reinterpret_cast<UNICODE_STRING*>(new BYTE[size]));
+    name.reset(static_cast<UNICODE_STRING*>(malloc(size)));
+    CHECK(name.get());

[rvargas (doing something else), 2013/06/05 22:27:36]

do we really net a check here?

[Derek Bruening, 2013/06/06 04:33:25]

Is there a Cr convention on OOM handling?  I saw many calls to malloc that do
not check the return value, and some that do.  I'm guessing the ones that don't
are assuming the shim wrapper is in place.  But for component build, the shim is
disabled and malloc goes straight to msvcrt.  Thus for component build OOM will
not call the new handler and will just return NULL.  If QueryObject were a
direct system call, then yes it would just fail nicely on a NULL: but as a
library layer it might go and crash strangely on us.  Hence, an explicit check
on the return value of malloc seems reasonable, right?

[jschuh, 2013/06/06 13:21:21]

Wouldn't a DCHECK be fine then? Since for all intents and purposes the component
build is debug only, and the CHECK is superfluous in release builds.

     result = QueryObject(handle, ObjectNameInformation, name.get(),
                          size, &size);
   } while (result == STATUS_INFO_LENGTH_MISMATCH ||