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.