`png_icc_profile_error` is no longer used when writing iCCP chunks,
therefore it can be compiled out when the reading is disabled.
This change includes two `minconfig` files to test read-only and
write-only "full" configurations, to supplement the existing tests
for "minimal" configurations.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
We should use `FILE *` instead of `FILE*` or `(FILE*)`, consistently,
as we should for all other pointer types. Moreover, when we refer to
standard stdio file objects in comments and in documentation, we should
use the term "FILE objects" consistently.
Lastly, we clarify in a comment in example.c that `PNG_STDIO_SUPPORTED`
is true only when the stdio support is both available in the system and
accessible in the user's libpng build.
This is a cherry-pick of commit c63c5463903014c904b540216c2784023fb8c1c8
from branch 'libpng18'.
Reviewed-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Remove #ifdef sections and other workarounds for old Windows compilers
that lacked proper support for Win32, including, especially, support
for the Win32 stdio API.
This is a cherry-pick of commit e936211760ddf0ed4a4711ea897b59395dfd206e
from branch 'libpng18'.
Reviewed-by: John Bowler <jbowler@acm.org>
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>
This is a regression of commit 2519a03418af2108d3bd8c269ba01ab72ae240ef
"refactor: Clean up the checking of chunk lengths and allocation limits"
Compilation would break under the "right" non-default configuration.
(Oopsie!)
Also clean up comments in the surrounding code.
Reported-by: chris0e3 <chris0e3@gmail.com>
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>
The two new configuation tests, fixed.dfa and float-fixed.dfa verify
that the 'standard' configuration of libpng works without floating point
arithmetic.
Signed-off-by: John Bowler <jbowler@acm.org>
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.
In libpng version 1.6.45 we inadvertently used a declaration after
a statement, which works for compilers supporting C99 and newer,
but fails with C89 compilers, which we are still supporting in the
branch 'libpng16'.
Moreover, in commit 92e8581f12d4570b777eaabfbe1f4243b7b80c04, we used
the macro `PNG_FIXED_EXPORT` in a manner that introduced a spurious ';'
character, which broke the build for all standard-conforming compilers.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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 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>
