Currently, libpng supports three different types of build automation:
the GNU autotools, CMake, and a legacy of hand-made makefiles.
In order to simplify the continous integration of all of the above
build options, we introduce the following scripts:
* ci_autotools.sh: CI utility for the Autotools build
* ci_cmake.sh: CI utility for the CMake build
* ci_legacy.sh: CI utility for the legacy makefiles
This adds the custom malloc/free functions from the old
libpng_read_fuzzer to the upstream fuzzer to prevent clusterfuzz
running into OOM.
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=904054
Contributed-by: Christopher Thompson <cthomp@chromium.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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>
It is unreliable to run pngtest in parallel, due to competing writes
to the same intermediate/output file ("pngout.png").
Customization of this output file name should be possible, but it is
currently broken.
If a zlib source tree exists besides the libpng source tree in the
same parent directory, the pngminus build may fail, unless the zlib
tree is built fully. In order to avoid this failing scenario, do not
use the custom-built zlib by default.
(The custom-built zlib is still necessary on platforms that lack a
system-built zlib.)
Change the license to MIT.
Move the license text from the source files to a LICENSE file.
Move the change log from the source files to a CHANGES file.
Delete the Turbo C makefile and simplify the Linux makefile heavily.
Create explicitly named static and shared executables in the makefile.
Refresh the README file a bit from the twenty year old one.
Signed-off-by: Willem van Schaik <willem@schaik.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.
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
Ensure that row_buf is deallocated not only after a read error, but
also after a write error.
Use the format "%p" instead of "0x%08lx" for printf-ing row_buf in
a portable manner.
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.
The branch 'libpng16' is for tracking libpng version 1.6.x.
The branch 'master' is for tracking the latest stable libpng version.
These branches will diverge again at the next major libpng upgrade.
The new libpng license comprises the terms and conditions from the zlib
license, and the disclaimer from the Boost license.
The legacy libpng license, used until libpng-1.6.35, is appended to the
new license, following the precedent established in the Python Software
Foundation License version 2.
From now on, the list of contributing authors shall be maintained in a
separate AUTHORS file.
The lists of previous contributing authors, mentioned in the legacy
libpng license and considered to be an integral part of that license,
are kept intact, with no further updates.
Although CMake version 3.0.2 was previously required, the policies
CMP0053 and CMP0054, introduced only in CMake version 3.1 and used
in this CMakeLists file, can have surprising effects under an older
CMake version.
Simplify the CMakeLists file by setting the global policy version
to 3.1, and remove the specific policy settings.
As an added bonus, remove the vestigial workarounds for all ancient
CMake versions.
Only use libm on Unix and Unix-like systems, except for Apple (where
it's unnecessary), and BeOS and Haiku (where it's unavailable).
Avoid searching for libm at explicit locations. They may be incorrect,
especially for cross-platform builds.
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.
