Specifically, this rejects length codes 286 and 287, and distance codes 30 and 31.
This avoids a scenario in which a file could contain a table in which
0 corresponded to length code 287, which would result in writing 0 bits.
Signed-off-by: Neil Bickford <nbickford@nvidia.com>
The component resamplers are not written to support this and I've
never seen it happen in a real (non-crafted) JPEG file so I'm
fine rejecting this as outright corrupt.
Fixes issue #1178.
As per MS's own docs, should ignore the r/g/b bitmasks in the
header unless BI_BITFIELDS compression is selected. Factor out
setting the default masks since that now exists in two branches.
Add some more checking for unsupported compression formats and
illegal bpp/compression combinations while I'm at it.
Fixes issue #783.
Put the formats that start with a clear magic number first,
the dodgy ones that don't have much of a distinctive header
should be tested for later after we've ruled out the clearer
ones.
Fixes issue #787, hopefully. (Never got a clean repro.)
It's implementation-specified behavior. Writing this code and then
relying on compiler strength reduction to turn it back into shifts
feels extremely silly but it is what it is.
Fixes issue #1097.
Define lrot in a way that doesn't involve UB when n==0.
Also, the previous patch ensures that n <= 15 for all callers
of stbi__extend_receive, so can remove the (less restrictive)
bounds check for 0 <= n < 17 (the bounds of stbi__bmask)
entirely.
Fixes issue #1065.
extend_receive implicitly requires n <= 15 (code length);
the maximum that actually makes sense for 8-bit baseline JPEG is
11, but 15 is the natural limit for us because the AC coding path
stores the number of magnitude bits in a nibble.
Check that DC delta bits are in range before attempting to call
extend_receive.
Fixes issue #1108.
Put the formats that start with a clear magic number first,
the dodgy ones that don't have much of a distinctive header
should be tested for later after we've ruled out the clearer
ones.
Fixes issue #787, hopefully. (Never got a clean repro.)
It's implementation-specified behavior. Writing this code and then
relying on compiler strength reduction to turn it back into shifts
feels extremely silly but it is what it is.
Fixes issue #1097.
Define lrot in a way that doesn't involve UB when n==0.
Also, the previous patch ensures that n <= 15 for all callers
of stbi__extend_receive, so can remove the (less restrictive)
bounds check for 0 <= n < 17 (the bounds of stbi__bmask)
entirely.
Fixes issue #1065.
extend_receive implicitly requires n <= 15 (code length);
the maximum that actually makes sense for 8-bit baseline JPEG is
11, but 15 is the natural limit for us because the AC coding path
stores the number of magnitude bits in a nibble.
Check that DC delta bits are in range before attempting to call
extend_receive.
Fixes issue #1108.
