Instead of resizing the bytearray to the potential size and then reading
into it, ask the device to read into a bytearray, this way instead of a
crash because we're trying to resize to a too big number we get a nice
maxSize argument exceeds QByteArray size limit
warning
oss-fuzz/46664
According to relicensecheck Brad is OK with changing LGPLv2 to LGPLv2+,
which is required to be compatible with the LGPL-2.1-or-later licensed
source files.
Since QImage does sanity checking for overflows and stuff wrt.
dimensions and depth, check for QImage::isNull() as early as possible to
see if there's some funky business going on.
Also tried to add some checks wherever we wrote to "raw" memory.
Unit tests pass, and tested converting some files from
https://samples.ffmpeg.org/image-samples/ to pngs, and that seemed to
work.
Reviewed By: aacid
Differential Revision: https://phabricator.kde.org/D24367
By using the same strategy as the SoftImage PIC handler (and sharing
some code with it), we should avoid reading the image data incorrectly
on big-endian architectures.
REVIEW: 122650
BUG: 337918
Frameworks have a convention of naming uninstalled headers in src/ with
a _p at the end of the name, to make it clear they are not part of the
API. None of the headers in KImageFormats are installed, so it is not
really necessary to follow this convention, but we follow it anyway for
the benefit of both humans and tools (like kapidox).
