This corrects contrib/testpngs/badpal/regression-palette-8.png. Despite
the comment in commit da109d3e the file checked in had 255 PLTE entries
so failed to perform the regression test. This version of the PNG has
254 entries.
Signed-off-by: John Bowler <jbowler@acm.org>
This adds a file to regression-test the previously introduced off-by-one
error in the check on read for a colormapped PNG with an out-of-range
index (equal or greater than the length of the PLTE).
Previous tests covered all cases except the 8-bit palette case; the
"small" test file contains the "bad" entry at index 254, not 255 so it
passes even if the final byte is not checked. The new file has the
erroneous entry in the last byte.
Signed-off-by: John Bowler <jbowler@acm.org>
The PNG IDAT did not include a '255' entry, the highest entry is '254',
this corrects the test PNG to have a palette with only 254 entries so
that it triggers the palette index checks.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The palette index checking function is called by default but only if
some *other* transformation is happening. This makes the 'get palette
max' public API disfunctional (sometimes it works, sometimes it returns
0) and causes the supposed default behaviour of checking the palette
index only to work sometimes. It works in pngtest, it doesn't work in
pngcp.
The check in pngread also has an off-by-one error; the number recorded
is the highest index found so it should be checked to ensure that it is
less than the palette length but it was checked for being greater.
The pull request includes a set of 8 files which all have the full range
of possible indices including one (the highest) which is invalid because
the PLTE chunk is one short of the maximum for each bit depth.
Signed-off-by: John Bowler <jbowler@acm.org>
