This is a regression of commit a8242dd9473a8da4d851623cf0b514a8ee4bee34
"PNGv3 colourspace precedence rules conformance".
Previously, `png_write_iCCP` used the length from the first four bytes
of the profile set by `png_set_iCCP`, rather than the actual data length
recorded by `png_set_iCCP`.
If the profile data were less than 4 bytes long, it would have caused
a read-beyond-end-of-malloc error. This bug was in the libpng code even
before the changes introduced in the above-mentioned commit, but it was
inaccessible. It became accessible when we removed the pre-PNGv3 colour
space checks in `png_set_iCCP`.
Reported-by: Bob Friesenhahn <bobjfriesenhahn@gmail.com>
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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>
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>
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 file contains hand-coded assembler implementations of the filter
functions for 32-bit Arm platforms. These are only used when the
compiler doesn't support neon intrinsics (added to GCC 4.3 in 2008) or
is exactly GCC 4.5.4 (released 2012), both of which are sufficiently
unlikely to be true that it's fair to say the assembler is no longer
used.
This commit deletes filter_neon.S and removes the now obsolete
preprocessor logic in pngpriv.h.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
In a similar manner as zlib (https://github.com/madler/zlib/pull/895),
libpng contains a header configuration that's no longer valid and
hasn't been exercised for the macOS target.
- The target OS conditional macros are misused. Specifically
`TARGET_OS_MAC` covers all Apple targets, including iOS, and it
should not be checked with `#if defined` as they would always be
defined (to either 1 or 0) on Apple platforms.
- `#include <fp.h>` no longer works for the macOS target and results
in a compilation failure. macOS ships all required functions in
`math.h`, and clients should use `math.h` instead.
This problem has not been noticed until a recent extension in clang
(https://github.com/llvm/llvm-project/pull/74676) exposed the issue
and broke libpng builds on Apple platforms. The failure can be
reproduced now by adding `#include <TargetConditionals.h>` before the
block.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
When compiling on the MIPS platform using the following command:
./configure --enable-hardware-optimizations && make
The options '-mmsa -mfp64' are not being passed.
PNG_MIPS_MSA_IMPLEMENTATION is defined as 2, leading to
the initialization of unimplemented MSA interfaces.
EXIF data can be stored in an eXIf chunk before IDAT, or after IDAT,
but the entire PNG datastream may contain one eXIf chunk at most.
Introduce the private mode flag PNG_WROTE_eXIf, which is meant to be
used like the PNG_WROTE_tIME flag. The eXIf chunk and the tIME chunk
have the same ordering rules (i.e. no constraints are imposed), and
the same multiplicity rules (i.e. no multiples are allowed), and they
should be initialized and checked using the same algorithm.
This fixes commit cd03aaf7bf0e0c748b8c6cb34a56b402b40d61d0,
previously reverted in 3d57708c9166419b7f5e0bbda2f7a2149112c844.
Reported-by: Ben Bullock <benkasminbullock@gmail.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.
Delete the structure members used in the 16-bit Turbo C memory models.
Delete the PNG_ABORT declaration used in the 16-bit Windows build.
Stop checking macros (e.g. _WINDOWS) predefined by 16-bit Windows
compilers (but do check the __NT__ macro, which was the only one
predefined by ancient Windows NT compilers).
This is similar to d532334ef (Avoid -Wundef warnings when building
libpng, 2017-11-13), but for the similar symbols used under the other
architectures: always define them, even if just as 0, to avoid gcc
warnings when comparing them with 0 later.
Define this symbol as 0 instead of leaving it undefined when not using
ARM NEON optimizations.
No real changes, but just avoid a bunch of
"PNG_ARM_NEON_IMPLEMENTATION" is not defined, evaluates to 0 [-Wundef]
warnings when building the library.
In order to appease the compiler warnings that might affect the uses
of png_constcast, it should be sufficient to cast the source pointer
type to (const void*), and then to (void*), and then to the destination
pointer type. An intermediate cast through an integer type, such as
(png_ptruint), should not be needed.
Fixes#398
It adds win-arm64 as an arm64 platform, by using a define which
is set to 1 for compilations that target 64-bit ARM processors,
otherwise undefined.
Move deallocation of riffled_palette from png_write_destroy to
png_read_destroy. The reader (not the writer) is the owner of
riffled_palette.
Move allocation and initialization of riffled_palette from
png_do_read_transformations to png_init_palette_transformations.
Allow riffled_palette inside png_struct only if the ARM Neon
optimizations are enabled.
Rename png_riffle_palette_rgba to png_riffle_palette_rgba8, etc.,
to better indicate the strict applicability of these routines.
Fix an unused parameter warning in the build configurations where
riffled palette optimization is not enabled.
Fix indentation.
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, size_t became a required type. It should be used
consistently. To maintain backwards compatibility, png_size_t
is still maintained in deprecated form.
