Fixed issue found by clusterfuzz

src/core/SkValidatingReadBuffer.cpp

Index: src/core/SkValidatingReadBuffer.cpp
diff --git a/src/core/SkValidatingReadBuffer.cpp b/src/core/SkValidatingReadBuffer.cpp
index 95bf83c847d313fdd6af4dbb7ad5f6291f9eacdf..0112f18ec44d5b922d9a0e4455e6975b371577df 100644
--- a/src/core/SkValidatingReadBuffer.cpp
+++ b/src/core/SkValidatingReadBuffer.cpp
@@ -91,7 +91,7 @@ int32_t SkValidatingReadBuffer::read32() {
 }
 
 void SkValidatingReadBuffer::readString(SkString* string) {
-    const size_t len = this->readInt();
+    const size_t len = this->readUInt();

[sugoi1, 2014/04/28 20:15:20]

Using readUInt() helps 64 bit platforms, since a "negative" int can no longer
turn into a very large 64 bit value, so an integer overflow is much less likely
on these platforms. For 32 bit platforms, see the fix to
SkReader32::isAvailable() (which would also fix the issue for 64 bit platforms).

[reed1, 2014/04/28 20:18:02]

Why is it readUInt() here, and readU32() in Reader.cpp?

[sugoi1, 2014/04/28 20:25:06]

I don't know the reason. I can see that SkReadBuffer::readUInt() calls
fReader.readU32() and it's probably been that way for a while.

     const void* ptr = fReader.peek();
     const char* cptr = (const char*)ptr;