Explicitly fail read/writePixels in invalid color space scenarios

It's not well defined what to do when moving from a nullptr color space to
a tagged destination (drawing, reading, writing, etc...). In these
scenarios, at least, we can choose to disallow the operation (rather than
produce an unexpected or inconsistent result).

BUG=skia:

Change-Id: I033b23c6f2bb00664efc8fdab1b3f52053d77695
Reviewed-on: https://skia-review.googlesource.com/6600
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>

1 files changed, 1 insertions, 2 deletions

diff --git a/tests/ImageTest.cpp b/tests/ImageTest.cpp
index 161dff8853..b2ac36d203 100644
--- a/tests/ImageTest.cpp
+++ b/tests/ImageTest.cpp
@@ -45,8 +45,7 @@ static void assert_equal(skiatest::Reporter* reporter, SkImage* a, const SkIRect
     // see https://bug.skia.org/3965
     //REPORTER_ASSERT(reporter, a->isOpaque() == b->isOpaque());
 
-    // The codecs may have given us back F16, we can't read from F16 raster to N32, only S32.
-    SkImageInfo info = SkImageInfo::MakeS32(widthA, heightA, a->alphaType());
+    SkImageInfo info = SkImageInfo::MakeN32(widthA, heightA, a->alphaType());
     SkAutoPixmapStorage pmapA, pmapB;
     pmapA.alloc(info);
     pmapB.alloc(info);