Fixed a few places where uninitialized memory could have been read

src/effects/SkColorMatrixFilter.cpp

Index: src/effects/SkColorMatrixFilter.cpp
diff --git a/src/effects/SkColorMatrixFilter.cpp b/src/effects/SkColorMatrixFilter.cpp
index 5b36a8f7e55df1dec60b77de2b29ba6fa81aec39..fc1b77b7d5e27f4f6ffbe4bf5ae2718daf3726d2 100644
--- a/src/effects/SkColorMatrixFilter.cpp
+++ b/src/effects/SkColorMatrixFilter.cpp
@@ -308,10 +308,8 @@ void SkColorMatrixFilter::flatten(SkFlattenableWriteBuffer& buffer) const {
 SkColorMatrixFilter::SkColorMatrixFilter(SkFlattenableReadBuffer& buffer)
         : INHERITED(buffer) {
     SkASSERT(buffer.getArrayCount() == 20);
-    buffer.readScalarArray(fMatrix.fMat, 20);
-    this->initState(fMatrix.fMat);
-    for (int i = 0; i < 20; ++i) {
-        buffer.validate(SkScalarIsFinite(fMatrix.fMat[i]));

[sugoi1, 2013/12/06 18:39:04]

I didn't find anything obviously wrong with removing the SkScalarIsFinite()
checks after doing some local tests and looking at the uses of fMat in the code.
It does use some arithmetic functions, like operators, min, abs, etc, but there
should be no further consequence to a NaN then turning the result into NaNs. If
these render on the GPU, NaNs may yield an undefined result, depending on the
hardware, but undefined behavior shouldn't cause security issues, hopefully
(maybe I'm wrong).
I don't think these calls had a significant cost (performancewise), though, so I
don't know how much can be gained by removing them, but, for now, I can just let
the fuzzer handle this and try to find issues with this, so that we can at least
know if there's an issue with this.

+    if (buffer.readScalarArray(fMatrix.fMat, 20)) {
+        this->initState(fMatrix.fMat);
     }
 }