If we modify the header of the gif to declare a size much bigger than the gif actually is (so, corrupted gif), we will allocate the theoritical maximum for no reason.
So, if the size of the inputstream is available (might not be the case), we could exist early if we detect that the size declared of the gif is more than 15 time bigger than the data stream)
For exemple, if we read the header and the gif is 100x100pixel, meaning 10000 pixels, but the gif size is only 100 bytes, then it's really fishy.
Similar to https://github.com/libjpeg-turbo/libjpeg-turbo/issues/560
If we modify the header of the gif to declare a size much bigger than the gif actually is (so, corrupted gif), we will allocate the theoritical maximum for no reason.
We could try to find a heuristic to exit early: A typical compression ratio of the gif seems to range between 4:1 to 10:1 (http://ist.uwaterloo.ca/~anderson/images/GIFvsJPEG/compression_rates.html)
So, if the size of the inputstream is available (might not be the case), we could exist early if we detect that the size declared of the gif is more than 15 time bigger than the data stream)
For exemple, if we read the header and the gif is 100x100pixel, meaning 10000 pixels, but the gif size is only 100 bytes, then it's really fishy.