Filx complier issue [-Werror, -Wvla]

src/codec/SkRawCodec.cpp

Index: src/codec/SkRawCodec.cpp
diff --git a/src/codec/SkRawCodec.cpp b/src/codec/SkRawCodec.cpp
index 05f18ac635918d448149fe112374ebd57636789c..d554c1934f93fac30b44e57440549dfe29a1b9f2 100644
--- a/src/codec/SkRawCodec.cpp
+++ b/src/codec/SkRawCodec.cpp
@@ -405,7 +405,9 @@ SkCodec::Result SkRawCodec::onGetPixels(const SkImageInfo& requestedInfo, void*
     }
 
     void* dstRow = dst;
-    uint8_t srcRow[width * 3];
+
+    static const int kStackBytes = 640 * 1024;  // Ought to be enough for anybody.

[msarett, 2016/01/27 14:51:05]

Any reason to not put this on the heap?

[yujieqin, 2016/01/27 14:53:00]

I do not have preference here. Just follow the code in
https://bugs.chromium.org/p/skia/issues/detail?id=4861#c1. 

Should I do somehow differently?

[mtklein, 2016/01/27 14:53:32]

Sorry, that number was a bit of a joke.  How long is a typical row?  Is it a
reasonable thing to put on the stack?

If not, SkAutoTMalloc<uint8_t> srcRow(width * 3); will put it on the heap
unconditionally as Matt suggests.

[yujieqin, 2016/01/27 14:57:53]

Normally I would think it should be around thousands of pixels. But it is not
possible to limit the width of an image somehow (e.g. panorama image). I think
the condition here could still be good?

[msarett, 2016/01/27 15:02:14]

Let's use this:
SkAutoTMalloc<uint8_t> srcRow(width * 3);

It matches our other codecs, it avoid putting a (potentially very large)
allocation on the stack, and it prevents us from worrying about how large width
can truly be.

[yujieqin, 2016/01/27 15:16:23]

Done.

+    SkAutoSTMalloc<kStackBytes, uint8_t> srcRow(width * 3);
 
     dng_pixel_buffer buffer;
     buffer.fData = &srcRow[0];