Use standard CMake variables in the install target.
Reformulate comments and error messages.
Move all CMake keywords in front of their arguments.
Fix indentation.
Update the ci_*.sh scripts and move them to the more conventional
ci/ directory. Update .appveyor.yml and .travis.yml, as well as
the AUTHORS file, accordingly.
Speed up ci_cmake.sh: add "-DPNG_TESTS=OFF" to the list of CMake
variables if CI_NO_TEST is true.
Remove "sudo: false" from .travis.yml.
Refactor .appveyor.yml.
Add the CMake option PNG_EXECUTABLES (on by default) in order to
allow or disallow the building of non-essential executable programs
associated with libpng.
Contributed-by: Alex Gaynor <alex.gaynor@gmail.com>
Contributed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
When building with Emscripten, linkage to libm is neither required
nor working. As find_library will fail, M_LIBRARY will be set to
NOTFOUND and the build would fail later. The build works just fine
without libm linkage.
I got a warning while compiling under Ubuntu 18.04 and gcc 7.4:
"__BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
Quote from the Linux Programmer's Manual:
"To allow code that requires _BSD_SOURCE in glibc 2.19 and earlier and
_DEFAULT_SOURCE in glibc 2.20 and later to compile without warnings,
define both _BSD_SOURCE and _DEFAULT_SOURCE."
Problem description:
Imagine a bitstream with an eXIf data segment that has invalid CRC.
If png_crc_finish() fails at line 2090, info_ptr->eXIf_buf is not freed
(despite the free_me setting at line 2062) because png_free_data() is
not called. png_read_info() is actually looping several time over the
png_eXIf chunk, calling png_handle_eXIf() several time in a row without
freeing the buffer.
This patch fixes the problem by leaving info_ptr's content in a clean
state in case of failure, as it is done at line 2084.
Delete variables (ALIGN, ARCH, DOCS) and targets (writelock) that are
no longer necessary.
Reorder the object file lists alphabetically, consistently across all
makefiles and build scripts.
Apply other minor fixes.
Exclude the branch "libpng16" from testing. It's identical to "master".
Also exclude the other (non-current) "libpng[0-1][0-7]" branches.
Parallelize the builds and the unit tests.
For Travis CI, update the build matrix as follows:
* On Linux, use both clang and gcc.
* On macOS, use clang only, with and without Xcode.
For AppVeyor CI, add a build matrix as follows:
* On Windows, use Microsoft Visual Studio 2019 on x86, x64 and arm64.
* Also on Windows, use MSYS2 on x86 and x64.
Use the new scripts/ci_*.sh; remove the old scripts/travis.sh.
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.
