This is a cherry-picked of commit f45531cc141dc20dc7a4046bbe92270b1e799a5d
from branch 'libpng18'.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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>
The code erroneously evaluated `addend0+addend1` in the case where
`addend1` is less than zero. The function is meant to subtract the
second argument from the first.
This is a cherry-pick of commit 79fd6d1edc8fe8c41ed58c6318bd57761d8f007e
from branch 'libpng18'.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The subtracts in PNG_XYZ_from_xy are producing integer overflow with
some valid but extreme xy values. This re-introduces the previous
checks, but with less limited bounds; sufficient to accomodate the
ACEScg end points (ACES AP1), but not for the ACES AP0 end points.
Those were not working anyway because libpng reads the cHRM parameters
as unsigned values, so they must always be at least 0.
A better solution requires recognizing reasonable negative values (ones
which violate the current spec) and allowing them too, at least on read.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
In `png_xy_from_XYZ` X+Y+Z was calculated without checking for overflow.
This fixes that by moving the correct code from `png_XYZ_normalize` into
a static function which is now used from `png_xy_from_XYZ`.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
ACES AP1 has a red endpoint with a negative Z, this triggers the checks
in libpng that ensure that x, y and z (chromaticities) are all >=0.
This removes the checks on the sign of the chromaticities since it is
valid to use negative values for any of them and converts the "internal"
error code return to external (because the internal cases correspond to
negative x, y or z.)
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This changes the mask used in the IHDR width check from ~7U to
~(png_alloc_size_t)7 which is a quantity at least as big as both
png_uint_32 and size_t whereas "7U" will be 16 bits on a 16 bit system.
The change both corrects a bug in the code (on 16 bit systems) and
removes compiler warnings about the test always being false on 64-bit
architectures.
Signed-off-by: John Bowler <jbowler@acm.org>
Mark the initialization of `png_signature[]` as static const inside the
function `png_sig_cmp`. This might be helpful to optimizing compilers.
Initialize the arrays `number_buf[]`, `digits[]` and `buffer[]` inside
the functions `png_convert_to_rfc1123_buffer`, `png_ascii_from_fixed`,
`png_warning_parameter_unsigned` and `png_warning_parameter_signed`.
Although these initializations are redundant, compilers such as gcc-13
fail to see the redundancy.
This removes pragmas and the controlling code that quelled warnings
generated by GCC7.1 (only) with -Wstrict-overflow=3 and possibly other
levels. Tested with GCC13.2, GCC7.1 is no longer the current version of
GCC7 (GCC7.5) and GCC7.1 was replaced by GCC7.2 on August 14, 2017.
Signed-off-by: John Bowler <jbowler@acm.org>
png_image_free_function (or any other destructor) should never fail.
Destructors need not and must not be executed under png_safe_execute.
Reference: CVE-2019-7317, use-after-free in png_image_free
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.
