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.
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>
By definition, `sizeof(png_byte)` is 1.
Remove all the occurences of `sizeof(png_byte)` from the code, and fix
a related typo in the libpng manual.
Also update the main .editorconfig file to reflect the fixing expected
by a FIXME note.
MSVC's <arm64_neon.h> header contains cl.exe intrinsics that are not
recognized by clang-cl.
Contributed-by: Ryan VanderMeulen <rvandermeulen@mozilla.com>
Contributed-by: Mike Klein <mtklein@google.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The memory leak remains fixed, but the associated refactoring is
being reverted. Moving the initialization of the riffled palette
from png_do_read_transformations to png_init_palette_transformations
has caused a regression in some of the test programs.
Although png_init_palette_transformations is the proper place to
perform this initialization, and the test programs are technically
incorrect to fail, we are still undoing that refactoring for the
time being.
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, 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.
result when integers appear on both sides of a compare. Worked around the
others by forcing the strict-overflow setting in the relevant functions to
a level where they are not reported.
Changed "FALL THROUGH" comments to "FALLTHROUGH" because GCC doesn't like
the space.
Worked around some C-style casts from (void*) because g++ 5.4.0 objects
to them.
Increased the buffer size for 'sprint' to pass the gcc 7.1.0 'sprint
overflow' check that is on by default with -Wall -Wextra.
As suggested in the comments gamma values outside the range currently permitted
by png_set_alpha_mode are useful for HDR data encoding. These values are
already permitted by png_set_gamma so it is reasonable caution to extend the
png_set_alpha_mode range as HDR imaging systems are starting to emerge.
Signed-off-by: John Bowler <jbowler@acm.org>
The old code incorrectly calculated the output rowbytes when the
application decreased either the number of channels or the bit depth (or
both) in a user transform. This was safe; libpng overallocated buffer
space (potentially by quite a lot; up to 4 times the amount required)
but, from 1.5.4 on, resulted in a png_error.
Signed-off-by: John Bowler <jbowler@acm.org>
input that was made in version 1.6.17beta01, to preserve legacy
behavior even though it was incorrect. Instead, added new API
png_set_filter_16() and png_set_add_alpha_16() that set a flag to
make png_do_read_filter() interpret the filler bytes properly.
