4 bits are read ([0, 15]) with 4 added to the result. The check that the
result is not > NUM_CODE_LENGTH_CODES (19) is redundant. This makes the
check an assert for documentation purposes.
webp-lossless-bitstream-spec.txt is updated accordingly.
Bug: webp:611
Change-Id: Ie461017dc9de3da4cfe6856543d3dcf58f53a180
ExpandColorMap() can fail due to a memory allocation failure.
Found by Nallocfuzz (https://github.com/catenacyber/nallocfuzz).
Change-Id: I868c5db2fee18e876f4aa3b63e744d7297d1a91b
in AllocateAlphaPlane() and VP8DecompressAlphaRows().
Found by Nallocfuzz (https://github.com/catenacyber/nallocfuzz).
Change-Id: I39eb305abfe9f4d7915cce5d91e72917f482bc20
This is unnecessary as green will have the largest value; the sizes are
currently: 256 + 24 + color_cache_size, 256, 40, in that order.
Change-Id: Ib9ce3292285a7b9c6089557b68a87184b68d17a5
The buffers are made mandatory to match WebPDecodeYUVInto(), though this
conflicts with WebPIDecGetYUVA().
spotted by Oliver Kunz (okunz at google dot com)
Change-Id: Ic4740c53b75da6b93d4f3462303fb9be0ebfbd48
and define it to true for __aarch64__ and Win Arm64 + Visual Studio.
Microsoft's compiler (cl.exe) does not define __aarch64__, but relies on
_M_ARM64 & _M_ARM64EC
Bug: b/277254922
Change-Id: I20e4fa07a4031599db69e3d7ba9050345315ef51
This avoids defining a version in each translation unit when using
__declspec(dllexport) which causes failures due to multiply defined
symbols with clang-cl:
lld-link: error: duplicate symbol: VP8GetCPUInfo
>>> defined at CMakeFiles\webpdecode.dir\Debug\src\dec\alpha_dec.c.obj
>>> defined at CMakeFiles\webpdsp.dir\Debug\src\dsp\dec_sse41.c.obj
...
Bug: webp:607
Change-Id: I6cd1ee75b3db984aa513263a05516e867a64925d
clears a warning of the form:
src/dec/webp_dec.c:182:62: runtime error: implicit conversion from type
'int' of value -2 (32-bit, signed) to type 'unsigned int' changed the
value to 4294967294 (32-bit, unsigned)
Bug: b/229626362
Change-Id: Ibf08f8bb9ec345381b51ca3872745368fca700c0
- prefer https
- metadataworkinggroup.org/com seem to be offline; the web archive link
was obtained from exiftool: https://exiftool.org/TagNames/MWG.html
- fix kramdown link, rubyforge has been gone a long time
- fix png/zlib links
Bug: webp:544
Bug: b/202302177
Change-Id: Id69de4553e7baf00393f12a2c1acb262443a1a93
to https://datatracker.ietf.org/doc/html/... the http tools.ietf.org
links redirect here sometimes, in other cases they 404.
Bug: webp:544
Change-Id: I900972070d6c5659c45a86a89e78b870f42fe5bc
use 64-bit math in calculating the offsets as they may exceed 32-bits
when scaling
Bug: chromium:1196850
Change-Id: I6a484fc4dded6f6c4b82346ef145eb69c1477b3c
promote out_width to size_t before multiplying
src/dec/io_dec.c:301:30: runtime error: signed integer overflow: 2 *
1224167500 cannot be represented in type 'int'
#0 0x55fd9e8de2bd in InitYUVRescaler src/dec/io_dec.c:301:30
#1 0x55fd9e8de2bd in CustomSetup src/dec/io_dec.c:571:54
Bug: chromium:1196850
Change-Id: I70d0aac1b5eef163a3f353b721fb9ab561e02040
in Export increment the dst pointer, but in EmitRescaledRowsRGBA use
64-bit math as the number of output lines is variable and may still
overflow when incrementing.
Bug: chromium:1196850
Change-Id: I5c65b875894ee9da0fef1e24d27e507171800c4a
with large sizes the intermediate calculations may exceed 32-bits
src/dec/io_dec.c:491:17: runtime error: signed integer overflow: 3 *
788529152 cannot be represented in type 'int'
#0 0x557a3ad972b2 in InitRGBRescaler src/dec/io_dec.c:491:17
#1 0x557a3ad972b2 in CustomSetup src/dec/io_dec.c:563:29
Bug: chromium:1196850
Change-Id: Iaf2e8a6de9481dfea31dcd7fccb2d4eca767bddf
with large scale values the offset to the end of the buffer may exceed
32-bits range.
src/dec/buffer_dec.c:158:39: runtime error: signed integer overflow: 2 *
1275068416 cannot be represented in type 'int'
#0 0x56444802bea5 in WebPFlipBuffer src/dec/buffer_dec.c:158:39
Bug: chromium:1196850
Change-Id: I08c8b69ada5d5dd3e9bf2b9006dffa0c5f2103a5
after the check using 64-bit math we used a signed integer in the
multiplication. previously unsigned integer max was tested.
fixes cases like:
src/dec/buffer_dec.c:108:16: runtime error: signed integer overflow:
944731466 * 4 cannot be represented in type 'int'
#0 0x55e56187dc1d in AllocateBuffer src/dec/buffer_dec.c:108:16
#1 0x55e56187dc1d in WebPAllocateDecBuffer src/dec/buffer_dec.c:216:12
...
Bug: chromium:1196850
Change-Id: I6e5b3e5d1d5b50b5c98c39bbf9813a63fedc5ca7
replace with more inclusive terms or remove the comment entirely if the
meaning was already clear.
Bug: webp:507
Change-Id: Ica3bbf751ebf79f6668df6e6209af770248ff4ca
this matches the description in WebPDecoderOptions and prevents a
mismatch between the user supplied options and the ones used by io.
Bug: chromium:1196773, chromium:1196775, chromium:1196480
Change-Id: I3603b806884cfc6969b093d06b7980b0cc13199b
this matches the description in WebPDecoderOptions and prevents a
mismatch between the user supplied options and the ones used by io.
Bug: chromium:1196480
Change-Id: Id464f999d737078078f9d21afe25b349317f5ab4
and avoid integer overflow in test of x/width and y/height parameters
against the image width/height
Bug: chromium:1196778, chromium:1196777, chromium:1196480
Change-Id: I7b8f1f4dbebfe073b1ba260b8317979488655dcc
if bypass_filtering was set to 1 in the user provided options it
shouldn't be reset in the use_scaling pass even if the image satisfies
the scaling requirements.
Change-Id: I036029907886acb63748872d5f8763954a7c607b
The offset *can* be negative, but the sanitizer reports strange
address behaviour when row_offset is unsigned size_t.
For safety, use int64_t instead (probably overkill. int32_t is probably ok).
Change-Id: I1bd424bfdb5447b3839f40679581d6bdea075320
this provides stronger synchronization when pthreads are available as
was done in 'd77bf512 add WEBP_DSP_INIT / WEBP_DSP_INIT_FUNC' for the
other init functions.
Change-Id: I2ffe4e24454d276c2411ece34dca38d23d4756d5
sometimes, the last rows of the alpha plane contain more than NUM_ARGB_CACHE_ROWS
rows to process. But ExtractAlphaRows() was repeatedly calling ApplyInverseTransforms()
without updating the dec->last_row_ field, which is the starting row used as starting
point.
Fix would consist of either updating correctly dec->last_row_ before calling
ApplyInverseTransforms(). Or pass the starting row explicitly, which is simpler.
BUG=webp:439
Change-Id: Id99f2c28662d02b2b866cb79e666050be9d59e04
