PNG_AFTER_IDAT was not set by the IDAT read code if unknown chunk
handling was turned on. This was hidden in the current tests by checks
within the text handling chunks. (For example, pngtest.png has a zTXt
chunk after IDAT.)
This change modifies both the sequential and the progressive reader to
reliably set PNG_AFTER_IDAT when the first non-IDAT chunk is seen and
before that chunk is processed.
The change is minimalist; PNG_HAVE_CHUNK_AFTER_IDAT can probably be
removed and replaced with PNG_AFTER_IDAT. Making the latter change is
something to be considered in libpng2.
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This reverts commit 34005e3d3d373c0c36898cc55eae48a79c8238a1.
Although I agreed with Lucas Chollet initially, I finally understood
the objection brought forth by John Bowler: "[...] it's not an
ancillary chunk type if it's not a chunk type in the first place."
I feel that more deliberation is needed on what a robust PNG decoder
should do when it stumbles upon a chunk type that fails to meet its
basic requirements. A clarifying recommendation for decoders may or
may not need to be stipulated in the PNG specification as well.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
nocompile-limits.dfa: turns off all limits including run-time limits
nolimits.dfa: makes the compile time limits unlimited while leaving on
the run-time limits.
Fixes compiler warnings exposed by these tests. These are just warnings,
there were no bugs other than a failure to handle systems with a 16-bit
at the appropriate time which would result in a later failure on malloc.
png.c: png_icc_check_length: in-line code was still used in place of
png_chunk_max when checking the current chunk allocation limit. The
in-line code did not handle PNG_MAXSEG_64K and, anyway, issued
compiler warnings in the 'nocompile-limits' case. Changed to use
png_malloc_max.
pngrutil.c: eliminated an erroneous 'truncation' warning with GCC-14 by
using a safe cast.
pngtest.c: failed to check for PNG_USER_LIMITS_SUPPORTED around API
calls which don't exist without PNG_USER_LIMITS.
Signed-off-by: John Bowler <jbowler@acm.org>
Internal changes only.
Move chunk length checks to fewer places:
Change `png_struct::user_chunk_malloc_max` to always have a non-zero
value, in order to avoid the need to check for zero in multiple places.
Add `png_chunk_max(png_ptr)`, a function-like macro defined in pngpriv.h
which expresses all the previous checks on the various USER_LIMITS and
system limitations. Replace the code which implemented such checks with
`png_chunk_max`.
Move the malloc limit length check in `png_read_chunk_header` to
`png_handle_chunk` and make it conditional on the chunk type.
Progressive reader: call `png_read_chunk_header`.
Correct the handling of pHYs.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This is a major change required by the new PNGv3 colour chunk precedence
rules. It **does not** change the libpng API (png.h) however it changes
the following handling of PNG files:
IFF the PNG file contains colour space information it changes from the
libpng v3 behaviour to the now compulsory PNG v3 behaviour:
1) libpng no longer invalidates colour space chunks because they are
inconsistent.
2) libpng no longer responds to the "png_get_" APIs positively if they
are not present in the PNG but can be deduced from the colour space
chunks that are present.
This adds APIs to get/set the two remaining new PNG-v3 colour space
chunks. The mDCV API matches that of cHRM. Both chunks support
floating point APIs (all values in the two chunks are real numbers).
Both chunks have a new encoded type, a four-digit-precision fixed-point
number, which cannot be represented in the existing `png_fixed_point`
type, so a `png_uint_32` is used.
Test examples for cICP, cLLI and mDCV are now in pngtest.png, and a
necessary change to the pngunknown.c test program has been made to
accomodate the additions.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Apply the following corrections and improvements:
* Add a validity check in `png_set_cICP`.
* Fix the ordering check in `png_handle_cICP`.
* Add a multiplicity check in `png_handle_cICP`.
* Optimize the implementation of `png_write_cICP`.
* Remove an unnecessary preprocessor guard from pngtest.c.
* Update the dependency declaration in pnglibconf.dfa.
* Fix the indentation where necessary.
This is a cherry-pick of commit c2a02691df1ecf51b7c97142752a7034350cb1f6
from branch 'libpng18'.
This chunk was added in the third edition of the PNG specification and
contains Coding Independent Code Points (related to color space
description). It is fairly simple as it only contains four fields of one
byte each: Colour Primaries, Transfer Function, Matrix Coefficients,
Video Full Range Flag.
The test file originally comes from the related WPT test case:
https://github.com/web-platform-tests/wpt/blob/master/png/support/cicp-display-p3.png
Note that I reencoded the file to make it match libpng's default
encoding parameters (it only modifies the IDAT chunk).
This is a cherry-pick of commit 65925ad4b2cbed934d5d850fe764dc46c4becbcb
from branch 'libpng18'.
Reviewed-by: John Bowler <jbowler@acm.org>
Reviewed-by: Chris Blume <ProgramMax@gmail.com>
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Move the definitions of interlace arrays to the top of their respective
translation units, to reduce their repeated copying in various places of
the codebase.
TODO:
As they still exist in three copies, in pngpread.c, in pngrutil.c, and
in pngwutil.c, they should all be further moved to a common place.
This is a cherry-pick of commit 620a2b73b22df66ed099e1faacac2d92f48252b7
from branch 'libpng18'.
The leading blank lines are apparently an artefact of an older source
control system. They are not required and they look like accidents,
because starting a source file with a blank line is not a regular habit
of software developers nowadays.
This is a cherry-pick of commit 37cc20add8fb5b83bb5299a26cd3b41e0f776017
from branch 'libpng18'.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This removes the default build of an undocumented feature to disable
Adler32 checksums on those systems where it was the default.
The PR is motived by github #187 however it fixes a much more general
problem (#187 is limited to an issue where libpng "crashes" on some
manufacturer systems). The fix is based on a suggestion by @sgowdev who
is the originator of the issue.
When libpng disables the checking of Adler32 checksums it does so by an
undocumented and therefore possibly unsupported call to a zlib function
which does not exist in some versions of zlib.
Fortunately libpng only does this if the caller of libpng explicitly
asks for it to happen. Unfortunately the call to the undocumented
function is still in the compiled and built libpng and this means that
on some systems (as identified in #187) libpng can fail to load or maybe
even crash.
The libpng authors are currently unaware of any program or system that
uses this feature and none has been identified by the contributors to
In this fix an option is added to *enable* the code so that by default
the code is *disabled* - this is a simple generalization of the
suggestion by @sgowdev.
BENEFITS: the problem is eliminated, users of the functionality, if any,
are idenfified, the functionality can be implemented correctly in the
future or it can be removed. Hardly anyone complains.
COSTS: someone will complain that they have to enable an option in a
libpng build to use a feature that never worked consistently in the
first place.
This patch has been tested both with the option enabled and with it
disabled via pngusr.dfa. Tests, checks pass with cmake and configure,
make distcheck passes on configure.
Reported-by: Stephen Gowen <dev.sgowen@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Import Chromium commit
e87a029871
Add the author to the list of libpng contributing authors.
Portions from the original commit message follow:
***
A recent change to libpng [1] (included in Chromium with the recent
libpng update [2]) turns chunks that are bigger than
PNG_USER_CHUNK_MALLOC_MAX into failures. Although this matches the
intent of PNG_USER_CHUNK_MALLOC_MAX, it also causes images which used to
be viewable in Chromium to fail. Changing to a benign error allows us to
display these images once again. Though it means we do allow libpng to
allocate more than PNG_USER_CHUNK_MALLOC_MAX, it matches the behavior
prior to [2] (when we were using 1.6.22), and it does not regress
crbug.com/117369
[1] 347538efbd
[2] f82653a473
***
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=827754
Co-authored-by: Leon Scroggins III <scroggo@google.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The check should fail if the EXIF byte-order header doesn't start with
a correct character, or if the two heading characters aren't identical.
Rewrite the check to make the code logic easier to follow.
The hIST chunks, used for storing image histograms, contain arrays of
16-bit unsigned integers, and the chunk size is expected to be an even
number. Raise a png_chunk_benign_error() if a hIST chunk fails to meet
this expectation.
Reported-by: Eugene Kliuchnikov <eustas@google.com>
The following pointer subtraction was unnecessary:
((const char*)(ptr)-(const char*)0)
In order to avoid further warnings about casting a wide pointer type
to a narrower integer type, we cast the pointer to the target integer
type through (size_t).
Also fix a comment and reformat the surrounding code.
Problem description:
Imagine a bitstream with an eXIf data segment that has invalid CRC.
If png_crc_finish() fails at line 2090, info_ptr->eXIf_buf is not freed
(despite the free_me setting at line 2062) because png_free_data() is
not called. png_read_info() is actually looping several time over the
png_eXIf chunk, calling png_handle_eXIf() several time in a row without
freeing the buffer.
This patch fixes the problem by leaving info_ptr's content in a clean
state in case of failure, as it is done at line 2084.
As per the const correctness rules, top-level const-ness of data
in automatic scopes does not propagate outside of these scopes
(unlike const-ness at lower levels, such as pointers to const data).
Previously, const was used liberally, but inconsistently across the
libpng codebase. Using const wherever applicable is not incorrect.
However, _consistent_ use of const is difficult to maintain in such
conditions.
In conclusion, we shall continue to use const only where doing so is
strictly necessary:
1. If a function guarantees that it will not modify an argument
passed by pointer, the corresponding function parameter should be
a pointer-to-const (const T *).
2. Static data should not be modified, therefore it should be const.
Reference:
Google C++ Style Guide
https://google.github.io/styleguide/cppguide.html#Use_of_const
In v1.6.0, compiler support for const became a requirement.
It should be used consistently. To maintain backwards compatibility,
PNG_CONST is still maintained in deprecated form.
In v1.6.0, size_t became a required type. It should be used
consistently. To maintain backwards compatibility, png_size_t
is still maintained in deprecated form.
