Switch to standard integer types in third_party/crashpad/.

third_party/crashpad/crashpad/client/crashpad_info.cc

Index: third_party/crashpad/crashpad/client/crashpad_info.cc
diff --git a/third_party/crashpad/crashpad/client/crashpad_info.cc b/third_party/crashpad/crashpad/client/crashpad_info.cc
index 596f3491c11a306e31d3ec797d25197b0108a76e..db71cc98ccacd8b41993c4cf783cb9301ca95b04 100644
--- a/third_party/crashpad/crashpad/client/crashpad_info.cc
+++ b/third_party/crashpad/crashpad/client/crashpad_info.cc
@@ -14,6 +14,7 @@
 
 #include "client/crashpad_info.h"
 
+#include "build/build_config.h"

[Mark Mentovai, 2015/12/28 00:26:18]

The .h already includes this. Is this not something you checked for?

[Avi (use Gerrit), 2015/12/28 00:37:13]

This is a practicality thing for me.

The tool does check the header file for things like <stdint.h>, because there's
no ordering issue. No one will be using uint8_t above the #include, so it
doesn't matter.

build/build_config.h is deadly, though. So so so so so many people use OS_*
without including that file, and it's super-easy to also use the OS_* macros
within the #include blocks, even before the line that includes build_config.h.

Therefore, in *any* file that uses the OS_* macros the tool includes
build_config.h. Then, when I review the includes, and I see build_config.h, I
stop to make sure that it precedes the use of OS_*.

If it were indirected through the header file, I wouldn't be able to guarantee
things. So I'm paying the price of overincluding that file to make damn sure
that the OS_* macros are defined when they're used, because the penalty of
getting it wrong is a silent miscompile. (Which, BTW, has happened at least
once; see https://codereview.chromium.org/1544083002/ .)

 #include "util/stdlib/cxx.h"
 
 #if defined(OS_MACOSX)