Change the cast in base::Location::Hash to uintptr_t.
This allows the appropriate HashPair function to be called depending on whether this is a 32 or 64-bit system.
On a 32-bit platform, using HashInts64 on 32-bit values doesn't buy us any
additional entropy (*hand-wavey*) compared to using HashInts32. It is more
expensive, generating an extra 4 64-bit multiplies, each results in a function
call (to _allmul) on Windows-32.
Review URL: https://codereview.chromium.org/1449173002
Cr-Commit-Position: refs/heads/master@{#362819}
CrOS-Libchrome-Original-Commit: 37d5552647f58f20069c485cf4203fe05839921b
diff --git a/base/location.h b/base/location.h
index 477dc02..8f77f7e 100644
--- a/base/location.h
+++ b/base/location.h
@@ -58,11 +58,7 @@
// it comes from __FILE__, so no need to check the contents of the string.
// See the definition of FROM_HERE in location.h, and how it is used
// elsewhere.
-
- // Due to inconsistent definitions of uint64_t and uintptr_t, casting the
- // file name pointer to a uintptr_t causes a compiler error for some
- // platforms. The solution is to explicitly cast it to a uint64_t.
- return base::HashPair(reinterpret_cast<uint64_t>(location.file_name()),
+ return base::HashPair(reinterpret_cast<uintptr_t>(location.file_name()),
location.line_number());
}
};