Detect the availability of `libm` on the target platform.
Previously, `libm` was detected on the host platform only.
Also introduce the variable `PNG_LINK_LIBRARIES`.
Stop using `M_LIBRARY`, which was not namespace-clean.
PNG_AFTER_IDAT was not set by the IDAT read code if unknown chunk
handling was turned on. This was hidden in the current tests by checks
within the text handling chunks. (For example, pngtest.png has a zTXt
chunk after IDAT.)
This change modifies both the sequential and the progressive reader to
reliably set PNG_AFTER_IDAT when the first non-IDAT chunk is seen and
before that chunk is processed.
The change is minimalist; PNG_HAVE_CHUNK_AFTER_IDAT can probably be
removed and replaced with PNG_AFTER_IDAT. Making the latter change is
something to be considered in libpng2.
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
In some cases, the vector extension is not supported, although the
compiler allows the "v" flag in `-march` and includes `<riscv_vector>`
without raising an error.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Add contrib/examples/.clang-format, tailored to fit the existing code
as closely as possible. The end goal is to set up automatic formatting
for the entire libpng source tree. We're doing this experiment in this
subdirectory, for now.
Also make refactoring changes, as follows:
* Rewrite the preprocessor checks `#if PNG_FOO_SUPPORTED` to stop
compilation immediately, with a descriptive `#error` about what
needs to be supported.
* Rewrite and reflow comments, add braces and brackets, and make other
minor modifications that are suited for the clang-format'ed code.
A funny thing happened while refactoring the function argument parsing
in the `PNGGenConfig` module: the processing of dependencies inside
the CMake function `generate_copy` got fixed, thanks to an inadvertent
typo correction!
Going down the rabbit hole, we uncovered two issues:
1. A typo in `scripts/cmake/PNGGenConfig.cmake` caused a dependency
declaration to disappear, disrupting the graph. Fortunately, this
disruption was being mitigated by an additional set of (redundant)
symbolic target declarations that kept the CMake build going.
2. The exact string matching inside `scripts/cmake/gensrc.cmake.in`
imposed an artificial limitation, disallowing the use of absolute
file paths.
The typo correction in (1), and the use of regex matching instead of
exact string matching in (2), allowed us to use absolute file paths
in the main CMake file, consistently, thus allowing CMake to recognize
them as uniquely-identifiable nodes in the dependency graph. There
should be no further need to have extra symbolic targets for proper
node identification.
In the end, we shaved off the redundant symbolic target declarations,
retaining only `png_genfiles` and `png_genprebuilt`.
Counter-intuitively, defining the PNG_DEBUG macro as 1 (i.e. setting
the debug verbosity level to 1) does *not* cause any of the existing
debug traces to show up. This setting would have worked if we had trace
statements like `png_debug(0, message)`, but we don't have any.
Debug traces do show up for verbosity levels from 2 to 5. The libpng
manual describes in detail how they are meant to be used.
According to the history of the CMake file, as well as the history of
other project files, PNG_DEBUG was never set to a numeric value larger
than 1. In other words, these debug settings inside these build files
never produced any output in any (unmodified) libpng version.
(As for the configure build, PNG_DEBUG has no special treatment there.)
Considering the plethora of alternative methods to pass C preprocessor
options through our build files, scripts and projects onto libpng, we'd
rather discontinue PNG_DEBUG as a dedicated build option.
Allow the CMake build to work properly, even if file paths (in the
source directory, in the build directory, or in the install directory)
might contain whitespace characters.
Improve the check for compilers that might use MSVC Runtime library
headers on Windows. We use POSIX-ish ("deprecated") functions, even
on Windows, and we want no spurious warnings.
Tidy up the CMake file: rearrange declarations, rewrite comments, etc.
When cross compiling for an apple platform on a non-apple platform
(or the reverse), `if(APPLE)` in line 32 should refer to the target
platform. Without importing the `APPLE` variable, it refers to the
host platform.
Reviewed-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The editorconfig-checker program is not installed by default in the OS
used by GitHub Actions. Fortunately, the editorconfig-checker authors
have kindly provided the action-editorconfig-checker repository, which
we are now using.
Also tidy up the new RISC-V code to comply with our coding style,
and rearrange comments inside png.h to improve readability within
the configured editing limits.
Running the pnglibconf scripts (script/*.awk) is not always possible.
An AWK interpreter is not always guaranteed to be available; and even
if it is, there are limitations when making cross-platform libpng
builds, especially when the differences between the host platform and
the target platform are significant. For example:
* Building for the Windows (MinGW) target on a Unix development host;
* Building for the iOS target on a macOS development host;
* Building for the Android target on any development host.
In such scenarios, a preconfigured (i.e. prebuilt) pnglibconf.h file,
either taken from the libpng source tree or provided by the user who
wants to make a custom libpng build, becomes a necessity.
In this commit we introduce the build option `PNG_LIBCONF_HEADER` in
order to address this specific use case.
We also specify a version range (3.14...4.0) for the minimum required
CMake program, to future-proof the CMake build for just a little bit
longer.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Make the error directives uniformly consistent with one another.
Remove surrounding quotes and trailing punctuation, and rephrase
some of the error messages and some of their associated comments
for either brevity or clarity.
Add checks inside the private png*.h header files, in order to reduce
unintentional occurences of application backdoors.
Such backdoors might occur, for example, when we make changes to the
internal data structures that might somehow "leak" from the libpng
code into the user code. The applications that use the libpng API must
pretend not to know that these headers exist at all.
Co-authored-by: John Bowler <jbowler@acm.org>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
`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>
In the floating-point API function `png_set_mDCv` we incorrectly
divided by two the chromaticity values before passing them on to
`png_set_mDCv_fixed`.
Reported-by: Mohit Bakshi <mohitbakshi2205@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This reverts commit 34005e3d3d373c0c36898cc55eae48a79c8238a1.
Although I agreed with Lucas Chollet initially, I finally understood
the objection brought forth by John Bowler: "[...] it's not an
ancillary chunk type if it's not a chunk type in the first place."
I feel that more deliberation is needed on what a robust PNG decoder
should do when it stumbles upon a chunk type that fails to meet its
basic requirements. A clarifying recommendation for decoders may or
may not need to be stipulated in the PNG specification as well.
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>
In addition to png.h, configure.ac and CMakeLists.txt, the script
ci_verify_version.sh is now able to verify libpng-config-head.in also.
For the benefit of readability, the old script ci_shellify.sh has been
split into smaller, independent scriptlets: libexec/ci_shellify_*.sh.
The linting script ci_lint.sh has been updated as needed.
For testing purposes (e.g. wanting to see if "make distclean" works
correctly with and without building), as well as development purposes
(e.g. wanting to inspect the artifacts produced in the configuration
stage), add `CI_NO_BUILD` to the family of contrarians.
pngimage: The code simply exited with a return code of 99 in the event
of a user error including giving pngimage invalid PNG files and an
internal error. It now attempts to clean up the state before doing so,
matching the normal behaviour.
pngimage: Non-ISO use of setjmp(3) corrected.
pngerror.c: Failure to call png_image_free on a false result from a
png_safe_execute function call fixed. This was a regression caused by
the 'volatile' clean-up. Not normally detectable because png_image_free
will often be called by the application.
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-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 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>
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.
Add various missing pieces to their right places:
* Update .editorconfig in order to let editorconfig-checker know that
aclocal.m4 (which is auto-generated) may contain trailing whitespace.
* Add ci/README.md.
* Update scripts/README.txt.
TODO:
Integrate editorconfig-checker into the linting workflow on GitHub.
(See .github/workflows/lint.yml)
Apply the following updates:
* Tidy up the compiler flag definitions.
* Update the Darwin, Linux and MSYS makefiles to match the compiler
flags used in scripts/makefile.clang and scripts/makefile.gcc.
* Add the `pngtest-static` target in the Darwin makefile, following
on the Linux makefile.
* Rewrite some of the implicit make rules to match one another more
consistently.
* Make corrections in the copyright years to match git log.
Add scripts/makefile.c89 and refactor scripts/makefile.emcc,
scripts/makefile.clang and scripts/makefile.gcc
Refactor variable definitions inside scripts/makefile.clang,
scripts/makefile.gcc and scripts/makefile.emcc, and start using
the option `-pedantic-errors` unconditionally. This option was
first implemented in GCC version 3.1, and it was available in
Clang and in other Clang-based compilers (e.g. Emscripten) from
the beginning.
Add scripts/makefile.c89, derived from the above makefiles, but
with `-pedantic-errors -std=c89`. We aren't enabling the C89 level
by default, to avoid any incompatibility, whether intentional or
accidental, with the compiler's default language level. However,
we are still continuing to support C89 in the 'libpng16' branch,
and this special makefile can be used for testing purposes.
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>
A downgrade from 16-bit samples to 8-bit samples, or an expansion from
1- or 2-channel grayscale (or grayscale+alpha) to 3- or 4-channel
RGB (or RGB+alpha), etc., may be deemed generally useful. Such image
transforms could be made available to the user via command-line options.
On the other hand, keeping the decision to disable or enable these
transforms unconditionally at compile time (e.g. because they're needed
to work around a specific printer's limitations) is less than ideal.
Apart from the png.h change, these files are machine-generated.
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>
In preparation for the upcoming changes in the build system, any parts
of the CMake file that are unlikely to be affected should be moved out
of the way. This should facilitate an easier resync between the branch
'libpng16' and its successor(s).
Specifically:
* Move the functions `generate_chk`, `generate_out`, `generate_source`
and `generate_copy` to scripts/cmake/PNGGenConfig.cmake.
* Move the function `png_add_test` to scripts/cmake/PNGTest.cmake.
* Leave the function `create_symlink` in place, but add a TODO note.
As we raised the minimum required CMake version to 3.14, we should
now be able to use CMake's built-in function instead.
cICP was written after PLTE, not before. The other chunks were output
in an order which does not match the new PNG-v3 "priority" order.
This change outputs all chunks in the "priority" order; highest
precedence first. This means that the PNGs so written conform to
PNG v3 (cICP), and allow a streaming app to handle chunks in order,
without buffering data which may later be overridden.
Note that PNG-v3 establishes the idea of dropping ancillary chunks
which are inconveniently ordered in the definition of how APNG chunks
are handled.
This is a cherry-pick of commit 945f2602a0ea05a7938b2f52df9ef16cf3440291
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>
For the sake of completeness:
* Add the cICP entry to the list of known chunks to ignore inside
`png_set_keep_unknown_chunks`.
* Handle cICP in `png_read_end`, alongside cHRM, gAMA, iCCP, sRGB.
* In pngtest.c, move the cICP test code near cHRM, gaMA, iCCP, sRGB.
This is a cherry-pick of commit 27c2ac722fd99b8622cead655034208ce96346ac
from branch 'libpng18'.
Reviewed-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Update the main CMake file and the auxiliary test scripts accordingly.
This is a cherry-pick of commit fe277b7752990be35523832a546aec478437968a
from branch 'libpng18'.
Apply the following corrections and improvements:
* Add a validity check in `png_set_cICP`.
* Fix the ordering check in `png_handle_cICP`.
* Add a multiplicity check in `png_handle_cICP`.
* Optimize the implementation of `png_write_cICP`.
* Remove an unnecessary preprocessor guard from pngtest.c.
* Update the dependency declaration in pnglibconf.dfa.
* Fix the indentation where necessary.
This is a cherry-pick of commit c2a02691df1ecf51b7c97142752a7034350cb1f6
from branch 'libpng18'.
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>
Embarcadero's compilers, old (Borland-based) and new (Clang-based),
do have full support for Standard C. The Clang-based compiler is
claiming, through the macro __STDC_VERSION__, to support C99 and C11,
whereas the Borland-based compiler supports ANSI C, as it has for
decades.
However, their run-time library is exposing global functions beyond
the scope of Standard C, for backwards compatibility with the older
Borland products. One of these functions is `randomize`, which clashes
with a function inside pngvalid.c that incidentally has the same name.
Building libpng in "Strict ANSI C" mode, in which all Borland-specific
globals are hidden (e.g. via `bcc32 -A`), would have been a workable
solution for the Borland-based ANSI C compiler, but no such solution
appears to exist for the Clang-based C90/C99/C11 compiler.
Fortunately, renaming a private function inside a test program is a
cost-free alternative fix.
This is a cherry-pick of commit 6184164aa73ee764b1822f44d3db7619cf84f3fa
from branch 'libpng18'.
Move the definitions of interlace arrays to the top of their respective
translation units, to reduce their repeated copying in various places of
the codebase.
TODO:
As they still exist in three copies, in pngpread.c, in pngrutil.c, and
in pngwutil.c, they should all be further moved to a common place.
This is a cherry-pick of commit 620a2b73b22df66ed099e1faacac2d92f48252b7
from branch 'libpng18'.
Disable the check on `interlace_method` inside function `compare_read`
in pngimage.c, if WRITE_INTERLACING is not supported.
If interlaced encoding is disabled inside libpng, the encoded images
are non-interlaced silently and unconditionally. This commit updates
the image comparison to skip the interlace check in the resultant
image; other behavior is still checked.
This is a cherry-pick of commit d9f13d8d846e08b00f6530b7a5fe07039d48c78d
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>
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>
Introduce CMake file linting, based on the cmakelang project by
Josh Bialkowski (@cheshirekow).
Fix various style issues in the CMake files:
* Add the missing copyright header to PNGConfig.cmake.
* Resolve a "missing docstring" warning raised by cmake-lint.
* Rewrite all docstrings in the style of CMake's own documentation.
* Fix whitespace inconsistencies.
References:
* https://pypi.org/project/cmakelang
* https://github.com/cheshirekow/cmake_format
This is a cherry-pick of commit c317fe31114d92d05d44bf98c9b559edf4656b9c
from branch 'libpng18'.
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>
Allow ci_verify_configure.sh to pass regardless whether the configure
script and the associated configure control files are present.
This is necessary for the branches newer than 'libpng16', where these
artifacts are no longer auto-generated by default.
This is a cherry-pick of commit 09ec97edc099538d548a67253b990660c912af4f
from branch 'libpng18'.
Due to raising the minimum CMake version to 3.14, we can now run the
CMake build verification (ci_verify_cmake.sh) from the libpng source
dir, just as in the other scripts (ci_verify_*.sh). This is possible
thanks to the modern CMake command options `cmake -B` and `cmake -S`.
We can finally simplify the implementation of ci_verify_cmake.sh by
removing a code complication that was annoying, and yet, necessary in
peculiar Bash-on-Windows setups.
Fun fact:
CMake version 3.14 was released on 2019-03-14. Reportedly, on purpose!
This is a cherry-pick of commit 558dfbb7570cb74205f978f11504b217a2c03c2c
from branch 'libpng18'.
Start using the features guaranteed to be available in CMake 3.14.
Specifically, use the ability of `find_package(ZLIB)` to pick up zlib
from the ZLIB_ROOT variable (if given).
This is a cherry-pick of commit 00343a761e41e56acaeb0517aec5325d3b951837
from branch 'libpng18'.
This changes the arm/palette_neon_intrinsics.c code from using a bare
cast to using the portable macro `png_aligncastconst`. This removes
the `-Wcast-align` warning.
The cast is safe because the pointer was allocated by `malloc(1024)`,
and `malloc` is required to return a pointer with sufficient alignment
for anything the allocation can accomodate.
Nevertheless, this is a quick and dirty fix; the use of `png_bytep` in
the `png_struct` declaration of the pointer is machine-specific. Other
architectures may need different types and, consequently, the only type
which is portable to other companies' CPUs is `(void*)`.
This is a cherry-pick of commit a604b12c112162bfb45a0476e956777f6ed82d85
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>
The MIPS MSA code contains // comments and the use of an "asm"
directive, neither of which are part of ISO-C90. This removes the //
comments and converts asm to __asm__, which GCC allows.
The code compiles but maintenance is required; it's not clear it will
work on anything other than one specific compiler/isa combination. It
should be rewritten using intrinsics, not assembler; as it stands it is
a security risk.
This is a cherry-pick of commit bd39ebbcfd64d785f907b5e8dd4055a97a34f2cf
from branch 'libpng18'.
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Reviewed-by: Chris Blume <ProgramMax@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Ignore artifacts produced by IDEs such as Embarcadero RAD Studio,
JetBrains Fleet, Qt Creator, and possibly others.
Also update the list of artifacts produced by C/C++ workflows and
CMake workflows in Microsoft Visual Studio and Qt Creator.
This is a cherry-pick of commit 10c76f3a1a9096f9b7cf64dd7abf5035e379e47f
from branch 'libpng18'.
Add projects/vstudio/build.bat, a wrapper for `devenv [...] /build`.
This is a cherry-pick of commit f1c01b5c36fc4fdcd9238c5295cc5565a9caa43e
from branch 'libpng18'.
Adjust the warning levels across the entire solution in order to tidy
up the build log.
Also remove the vestigial macro definition _USRDLL and add the missing
macro definition _CRT_SECURE_NO_WARNINGS.
This is a cherry-pick of commit 719705a2ab932a353748371c2e57f39ebc4bb8a3
from branch 'libpng18'.
This corrects the checks to that libpng 10800 does not turn on the
enhanced transform checks in either pngvalid or pngstest. The correct
fix is to change the 10700 code for comments which explain what aspect
or aspects of the transforms are broken (ideally) or at least state that
the transforms are broken.
This is a cherry-pick of commit aec888ab80f5d2241b3515b60f0f9337108fb624
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>
This reverts commit b7276eca0182bb6ad174ef044bb5f6f0504451af.
Although the brand new pngfuzz repo is coming up next, it turned out
that the deletion of contrib/oss-fuzz/ from the 'libpng16' branch was
premature. (Oopsie!)
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
As the editorconfig-checker program is transitioning from using
the .ecrc config file to the .editorconfig-checker.json config file,
the older program versions do not recognize the new config file name.
Update ci_lint.sh to instruct editorconfig-checker to pick up its
configuration from the new config file name, regardless of the program
version.
Also update ci_lint.sh to instruct yamllint to check all *.json files,
including .editorconfig-checker.json.
This is a cherry-pick of commit 77f88338a19a223cc678e1a6a04888a31c78dabf
from branch 'libpng18'.
Also add an .editorconfig-checker.json file. We need to instruct the
editorconfig-checker program to skip the checks for the indent size.
(As of this commit time, editorconfig-checker is too rigid to recognize
"smart indentations".)
This is a cherry-pick of commit 67c99f75cf05b354f89c01c8fc15948300e84143
from branch 'libpng18'.
Co-authored-by: John Bowler <jbowler@acm.org>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Ignore the files and the directories that are typically produced by
text editors, development tools, development environments, etc.
This is a cherry-pick of commit 050aa7bb936c8889a41942b0b83f5db8582bce17
from branch 'libpng18'.
A new repository named "pngfuzz", dedicated to fuzz testing PNG
processing software in general and libpng in particular, has been
created:
https://github.com/pnggroup/pngfuzz
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>
Properly declare target include directories for generated includes.
Previously the non targeted `include_directories()` was used, which
had issue when using the `png_static` target in a submodule.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Properly declare target include directories for generated includes.
Previously the non targeted `include_directories()` was used, which
had issue when using the `png_static` target in a submodule.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Going forward, we will continue to verify the cmake build and the
configure build with the hardware optimizations enabled by default,
and the makefile build with the hardware optimizations disabled by
default.
The Travis CI configuration file is simpler, and, more importantly,
the Travis CI verification process will be shorter and cheaper.
In "test: Add consistency checks for the PNG_LIBPNG_VER* number" [0] the
`STDERR` macro was moved from outside an `ifdef` to inside an `ifdef`.
This broke the code in the `else` of this `ifdef` which also uses the
`STDERR` macro. Move `STDERR` back to where it was to avoid compile
errors in the `else` case.
[0] cc8006c48dFixes: #560
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
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>
Considering that a non-trivial amount of libpng code is arch-specific,
we should perform cross-platform builds (with cross-platform toolchains)
and test runs (on emulated architectures) in our routine verification.
The content of ci/targets/ shall consist of target description files,
written in the standard shell language. These files may be source'd as
needed, before running the verification scripts ci/ci_verify_*.sh.
Here is the initial list of target systems:
Android, Cygwin, FreeBSD, Linux, MSDOS, Windows.
And here is the initial list of target architectures:
ARM, MIPS, PowerPC, RISC-V, x86.
Because of a missing "amd64" string (in lowercase) in a regex match,
the CMake build was unable to pick up the PNG_HARDWARE_OPTIMIZATIONS
flag on FreeBSD/amd64 (and possibly other amd64 systems as well).
Rename the target arch variable from TARGET_ARCH to a more idiomatic
PNG_TARGET_ARCHITECTURE, and set it to an always-lowercase string.
The follow-on checks are now simpler and easier to get right.
Initialize the arch-specific MSYSTEM environment variable, to ensure
that msys2 bash picks up and executes /etc/profile correctly.
Install and use the host-specific cmake and ninja, to ensure that
msys2 cmake picks up the host-specific zlib build correctly.
In the previous commit 9e538750d99c8f1accf7e93878e4fde47c069908
we removed the obsolete assembler implementation `filter_neon.S`.
In this commit we add a stand-in for the original file, restoring
the original source tree structure, for the benefit of continuing
hassle-free libpng source upgrades in the 1.6.x line.
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>
This fixes the bug https://github.com/pnggroup/libpng/issues/505
"libpng does not support PAC/BTI on aarch64 targets" which arises
because the build mechanisms (both cmake and configure) assemble
arm/filter_neon.S even though it ends up completely empty. The empty
file effectively poisons the so that the PAC/BTI support gets disabled.
The fix is minimal; it simply removes arm/filter_neon.S from the list of
sources included in the 64-bit ARM builds build. Note that this was
already done in cmake for MSVC - it's not clear whether this change was
a partial fix for the same issue.
This version of the fix ONLY affects aarch64 (arm64) builds; 32-bit ARM
systems can still invoke the assembler if required and, indeed, there
should be no change whatsover to those builds.
The assembler code could not be used on 64-bit systems in any case so
in practice there is no material change to 64-bit builds either.
TESTING: pull the changes then type "autoreconf" if using configure (not
required for cmake).
TESTS: cmake has not been tested because cross-builds with cmake
currently fail to find the zlib installation from the cmake system root
path. The following has been tested with configure cross builds:
armv7-linux-gnueabi [no neon support]
armv7a-linux-gnueabi [no neon support]
armv7a-hardfloat-linux-gnueabi [neon support not enabled]
armv7a-hardfloat-linux-gnueabi -mfpu=neon [uses intrinics]
armv7a-hardfloat-linux-gnueabi -mfpu=neon
-DPNG_ARM_NEON_IMPLEMENTATION=2 [uses assembler]
aarch64-linux-gnu [uses intrinsics]
aarch64-linux-gnu -DPNG_ARM_NEON_OPT=0 [neon support disabled]
Signed-off-by: John Bowler <jbowler@acm.org>
We used this experimental project in the development of the PNG-EXIF
("eXIf") specification, back in 2017. The project evolved together
with the draft specification, which was finalized on 2017-Jun-15 and
approved by the PNG Group on 2017-Jul-13.
The EXIF specification, outside of the scope of PNG and libpng, is
quite complex. The libpng implementation cannot grow too much beyond
performing basic integrity checks on top of serialization. In order
to create and manipulate PNG-EXIF image files, the use of external
libraries and tools such as ExifTool is necessary.
Now, with the addition of contrib/pngexif to the libpng repository,
offline tasks like metadata inspection and linting can be performed
without importing external dependencies.
Modern compilers can disable the warnings that originate from system
headers. This change allows them to do so with the libpng headers.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
In the configure script, checking whether the LoongArch LSX intrinsics
are supported by the compiler was done unconditionally, regardless of
the targetted host platform. Compared to how we support the other SIMD
platforms and compilers, this is rather unconventional.
We are placing this check under the guard of its own platform, for the
time being. A full solution, in line with the rest of the configure.ac
patterns concering SIMD optimizations, is TODO.
We also do an overall cleanup in the SIMD section of configure.ac, and,
finally, we regenerate the configure script.
Declare AWK explicitly via the AC_ARG_VAR directive, in order to make
it "precious", and to include it in the list of influential variables
at the end of the configure help text.
Rephrase a few comments and config traces.
Finally, regenerate the configure script.
Update the PNG_TOOLS option: set it to OFF by default when the
target is an embedded system, yet still allow it to be overridden.
Update the PNG_FRAMEWORK option: force it back to OFF and print a
warning if the option was ON but the target is not an Apple system.
This fixes commit 4edbb4da81626a7342a22824d7a8f60a3ea71bd0.
During the move of CMake scripts to the scripts/cmake/ subdirectory,
some of the workflows have been broken.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This fixes commit dddaf0c625a8daea4d027cb57380b7fac6f58285.
The way to reliably `find` executable files is different on BSD, Mac
and Linux, unfortunately.
The variable `CI_LINT_COUNTER` was incremented inside subshells, but
remained unchanged in the main shell process. The errors detected by
the internal linters remained unreported by the main script. (Oopsie!)
Besides fixing this defect, considering that only a pass/fail status
is needed, we are replacing `CI_LINT_COUNTER` with `CI_LINT_STATUS`.
Introduce the environment option CI_FORCE:
* ci_verify_configure.sh is known to fail if an existing build
configuration is found in the top-level directory.
Setting CI_FORCE=1 will run `make distclean` before verification.
* ci_verify_makefiles.sh cannot be reliably executed if random
object files are found in the top-level directory.
Setting CI_FORCE=1 will run `rm *.o *.obj` before verification.
* ci_verify_cmake.sh is not known at this time to fail for similar
reasons; but if it does, we will use CI_FORCE to trigger any
necessary pre-build cleanup.
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.
Work around a limitation in the `shellcheck source` directive, which
does not recognize quotes in shellcheck versions older than 0.9.
Also extend the checks for YAML files over the entire source tree, in
preparation for the introduction of the GitHub Actions config file.
`PNG_LIBPNG_VER_BUILD` should be zero for public releases and non-zero
for development versions. The ci_verify_version.sh script should check
this requirement as such.
Split AR_RC into AR and ARFLAGS. The variables AR and ARFLAGS are
de-facto standards (like CC and CFLAGS, LD and LDFLAGS, etc.) that
may be overridden when running make. Moreover, configuring CC, LD,
AR, etc., to point to a cross-platform compiler, linker, librarian,
etc., is a de-facto standard practice as well.
Also remove the MKDIR_P variable definitions from all makefiles.
They've been leftovers from the removal of the "install*" targets.
This program verifies the libpng source tree, expecting consistent
definitions of version numbers in the C source code, in the Autoconf
scripts, and in the CMake scripts.
The version verification is performed as follows. (Please note that
the version definitions in png.h are checked twice.)
* The files png.h, configure.ac and CMakeLists.txt are checked by
the ci_verify_version.sh program.
* The files png.h, png.c and pngtest.c are checked by the pngtest
program.
The version macros `PNG_LIBPNG_VER_SONUM` and `PNG_LIBPNG_VER_DLLNUM`
weren't always in sync, but they should be, going forward.
Or, better yet, we should keep them in, deprecated, and introduce
`PNG_LIBPNG_VER_SHAREDLIB` for all shared library builds of all kinds
on all platforms.
It is unknown how many user applications have been using these macros.
We have been using `PNG_LIBPNG_VER_DLLNUM` for pngwin.rc, for example.
Which, by the way, was last updated in 2009.
We have been running address-sanitized CI verifications for a while.
We can finally afford to simplify pngtest.c by removing a compile-time
option and the associated code branches that used to serve (only to a
limited extent) the purpose of bounds checking.
Also change the brief description of pngtest.c at the top of the file.
This is no longer just a simple test program.
Improve:
The pngtest program used to be rather relaxed upon seeing invalid
parameters in callbacks: it either ignored them, or it bailed out
of the callbacks, essentially sweeping the bug under the rug.
But no more. Now it terminates with a severe `png_error`, in which
it says what's broken and where.
Improve:
`PNG_DEBUG`, defined externally at build time, and defaulting to zero,
was assumed to be non-negative. Now it's checked.
Clean up:
In a very distant past, the pngtest program used to "travel" across
libpng versions, on its own, not necessarily accompanied by the actual
library version that it was meant to test. However, this stopped being
the case, and now is as good a time as any to remove the compatibility
workarounds that had made the aforementioned "travel" possible.
Other chores include:
* The refactoring of the user-defined chunk handling routines;
* The cleanup of an unnecessary use of volatile;
* The various cosmetic improvements of code and comments.
This adds a new configuration file, 'contrib/conftest/basic.dfa' which
disables unused APIs on a test Linux-based system. So support the
configuration several fixes were necessary in the test programs so that
the tests are skipped correctly when APIs are not available.
The configuration has been tested on a range of common Linux apps
including web browser code (qtwebengine), image processing code (e.g.
ImageMagick) and general display code (X11, Qt5 and Qt6, KDE). Overall
this first step reduces libpng linked code and data size to about 2/3 of
the full configuration.
To use the new test simply copy basic.dfa to 'pngusr.dfa' in the root of
the source directory and build.
Signed-off-by: John Bowler <jbowler@acm.org>
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>
This was broken by the corrections to the 'palette max' handling; if
that is disabled the test of num_palette_max must be removed in pnread.c
Signed-off-by: John Bowler <jbowler@acm.org>
This fixes commit 27e548af2518ff8d278b45c40d11ad1bdd68eaa0.
The macro `png_check_sig` has been deprecated and remained untested
for decades. And yet, somehow it escaped from all past API cleanups.
Also update the libpng manual.
Reported-by: Matthieu Darbois
Many build scripts, ports and other third-party add-ons that are
circulating around appear to be distributed under the MIT License.
Examples include the Vcpkg build system (including the libpng port)
and the Meson build definitions (including the libpng definition).
I am, therefore, relicensing our CI scripts once more, as the sole
author (so far), just in case that any of the CI code might travel
from/to such projects. Hopefully, this one last license will stick.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
From the libpng licensing point of view, the build projects, the build
scripts, the test scripts, the CI verification scripts, et cetera, have
not traditionally been part of libpng proper, although some of these,
including the CMake-based build, have been released under the libpng
license.
Considering how the CMake build grew as a result of many contributions
from many contributing authors over a long time, one may argue that it
almost became an individual piece of software in its own right.
Moving on, everything CMake-related shall be placed in the subdirectory
scripts/cmake/ (except, of course, the main CMakeLists.txt). Moreover,
contributing authors shall be acknowledged in scripts/cmake/AUTHORS.md.
Please see scripts/cmake/README.md for more information.
Bring the auto-generated scripts up to date with the autoconf upgrade
from version 2.71 to version 2.72.
Make the .gitignore exclusions better tailored to the autoconf- and
configure-generated artifacts.
Move all Autoconf macro files (except for those that need to be in
the top-level directory) to their own subdirectory scripts/autoconf/
In this commit, we introduce a better way to organize the scripts dir,
and we make a better separation between the build scripts under the
libpng license vs. the build scripts that fall under other licenses.
Please see scripts/autoconf/README.md for more information.
Previously the 'make check' test pngtest-all looked for given messages
at EOL. The match failed with Windows/MSYS2 because of the Windows
<cr><lf> line endings output by pngtest. This changes the test to look
for the message anywhere in a line; this might give false matches but
the specific messages being searched for are not likely to cause this
problem.
Signed-off-by: John Bowler <jbowler@acm.org>
The test always failed on systems with no support for zlib
inflateValidate and on systems where the png_set_option setting was
disabled, however pngtest-all succeeded because the failure was ignored.
The latter is now fixed so the badadler.png check needs to use --xfail,
not --relaxed.
Signed-off-by: John Bowler <jbowler@acm.org>
This corrects contrib/testpngs/badpal/regression-palette-8.png. Despite
the comment in commit da109d3e the file checked in had 255 PLTE entries
so failed to perform the regression test. This version of the PNG has
254 entries.
Signed-off-by: John Bowler <jbowler@acm.org>
The last byte of each row was ignored in a function that was executed
under the build flags `PNG_READ_CHECK_FOR_INVALID_INDEX_SUPPORTED` and
`PNG_WRITE_CHECK_FOR_INVALID_INDEX_SUPPORTED`.
This is a revert of a change previously applied in libpng-1.6.33beta01.
See SourceForge bug #269 at https://sourceforge.net/p/libpng/bugs/269/
Reviewed-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This change is only verifiable in configure builds; cmake only executes
the basic test.
The previous version of tests/pngtest-all only returned the status code
of the final test. Apparently it could never fail. This adds checking
of all return status codes.
The change also adds a basic approach for regression testing with PNGs
that should fail a test; --strict ensures that PNGs which are valid do
not start to be reported as erroneous, this is the inverse.
At present the code (minimal traditional Bourne shell) only tests the
palette index checking code, a potentially important check if apps rely
on it.
The changes have been tested using the configure build both with a
regression which causes the libpng checking to cease to work and with a
corrected (reverted regression). The regression test verifies that the
intended check works as expected.
Signed-off-by: John Bowler <jbowler@acm.org>
This removes the default build of an undocumented feature to disable
Adler32 checksums on those systems where it was the default.
The PR is motived by github #187 however it fixes a much more general
problem (#187 is limited to an issue where libpng "crashes" on some
manufacturer systems). The fix is based on a suggestion by @sgowdev who
is the originator of the issue.
When libpng disables the checking of Adler32 checksums it does so by an
undocumented and therefore possibly unsupported call to a zlib function
which does not exist in some versions of zlib.
Fortunately libpng only does this if the caller of libpng explicitly
asks for it to happen. Unfortunately the call to the undocumented
function is still in the compiled and built libpng and this means that
on some systems (as identified in #187) libpng can fail to load or maybe
even crash.
The libpng authors are currently unaware of any program or system that
uses this feature and none has been identified by the contributors to
In this fix an option is added to *enable* the code so that by default
the code is *disabled* - this is a simple generalization of the
suggestion by @sgowdev.
BENEFITS: the problem is eliminated, users of the functionality, if any,
are idenfified, the functionality can be implemented correctly in the
future or it can be removed. Hardly anyone complains.
COSTS: someone will complain that they have to enable an option in a
libpng build to use a feature that never worked consistently in the
first place.
This patch has been tested both with the option enabled and with it
disabled via pngusr.dfa. Tests, checks pass with cmake and configure,
make distcheck passes on configure.
Reported-by: Stephen Gowen <dev.sgowen@gmail.com>
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This adds a file to regression-test the previously introduced off-by-one
error in the check on read for a colormapped PNG with an out-of-range
index (equal or greater than the length of the PLTE).
Previous tests covered all cases except the 8-bit palette case; the
"small" test file contains the "bad" entry at index 254, not 255 so it
passes even if the final byte is not checked. The new file has the
erroneous entry in the last byte.
Signed-off-by: John Bowler <jbowler@acm.org>
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.
`png_safe_execute` called `setjmp` in a context where the result was
undefined (an assignment statement). This corrects the code and removes
volatile statements that were introduced previously to quell warnings
from earlier versions of GCC.
Co-authored-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.
The PNG IDAT did not include a '255' entry, the highest entry is '254',
this corrects the test PNG to have a palette with only 254 entries so
that it triggers the palette index checks.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The write palette check is off-by-one when checking the maximum palette
index against the number of entries however, because of the
implementation, the simple correction would fail if no palette check had
been performed (for example for a non-palette image). This corrects
both errors so that the code outputs a warning (but not an error) if a
user of libpng writes an image with a PLTE which is one entry short.
The write palette check can be turned off on colour type 3 images
(colour mapping images) but this is done by setting the 'maximum'
palette index in the image to (-1). The ammended code works because it
only executes for paletted images, it is dependent on palette checks
being compiled in and they will always be checked unless the stored
'max' value is less than 0.
Signed-off-by: John Bowler <jbowler@acm.org>
The palette index checking function is called by default but only if
some *other* transformation is happening. This makes the 'get palette
max' public API disfunctional (sometimes it works, sometimes it returns
0) and causes the supposed default behaviour of checking the palette
index only to work sometimes. It works in pngtest, it doesn't work in
pngcp.
The check in pngread also has an off-by-one error; the number recorded
is the highest index found so it should be checked to ensure that it is
less than the palette length but it was checked for being greater.
The pull request includes a set of 8 files which all have the full range
of possible indices including one (the highest) which is invalid because
the PLTE chunk is one short of the maximum for each bit depth.
Signed-off-by: John Bowler <jbowler@acm.org>
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>
Previously pngfix had been made warning-free in GCC7.1 by marking auto
variables (volatile). This prevented the arithmetic optimizations which
caused warnings from GCC7.1 with higher values -Wstrict-overflow=<n>
GCC has moved on a lot since 7.1 and pngfix.c now compiles with just one
warning using -Wstrict-overflow=5. The change includes a change to make
this go away by performing the rearrangement GCC was using in the code:
i == ndigits-1
becomes:
i+1 == ndigits
i is initialized to ndigits and has been decremented at least once so
this is fine.
Test, configure:
CFLAGS="-Wall -Wextra -Wno-maybe-uninitialized -Wstrict-overflow=5" \
../configure --enable-werror
make
make cehck
Test, cmake:
cmake ..
make
make test
Signed-off-by: John Bowler <jbowler@acm.org>
Prior versons of the GCC warned about the 'dest' parameter of
contrib/tools/pngcp.c not being volatile, which isn't necessary because
it isn't modified. This removes the GCC specific fixup.
The function which calls setjmp, cppng() also relied on undefined
behavior because it assigned the result of setjmp() to a variable; this
is not one of the four uses of setjmp permitted by ANSI-C. This passes
the result previously returned by longjmp via (struct display). It's
very very unlikely that any compiler could have got the code wrong but
it is technically undefined.
At a certain step in the configuration process, `gcc -Wundef`
complained about using `INT_MAX` without a definition in png.h,
which is easily fixable with an include.
We would rather not add any extra dependencies to png.h, however,
so we use some unsigned int arithmetic magic instead.
Defer the program termination on error until all files are closed and
(if applicable) all incompletely-written output files are deleted.
In addition, perform the following maintenance tasks:
* Rename and document the internal helpers used by the functions
`png2pnm` and `pnm2png`.
* Unset the executable permission bits for the *.bat test programs.
The pngminus programs use several PNG image transformations:
`png_set_expand`, `png_set_expand_1_2_4_to_8`, etc. (in png2pnm.c);
`png_set_packing`, `png_set_invert_mono`, etc. (in pnm2png.c).
The availability of all of these transformations in libpng is now
required at compile time.
On the topic of transformations, apply an unrelated fix to the use
of `png_set_gamma`.
Improve and modernize png2pnm.c:
* Remove the explicit reading of the input PNG file signature.
Libpng is now able to read it, check it, and issue an appropriate
error message in case of magic number mismatch or file corruption.
(See the function `png_read_sig`.)
* Remove the explicit allocation and dealocation of the image data.
Libpng is now able to manage all the image data automatically.
(See the function `png_read_png`.)
* Specify the needed image transformations without a-priori checking
the image type for applicability.
* Use the `png_set_expand_gray_1_2_4_to_8` transformation.
Since libpng version 1.2.9, this transformation (if needed) must
be enabled separately from `png_set_expand`.
Improve and modernize pnm2png.c:
* Modify the allocation of image data, in order to match libpng's
internal allocation model.
* Transfer the ownership of the image data from the `pnm2png` function
to libpng, which will manage and dealocate it at the right time.
(See the functions `png_set_image_rows` and `png_data_freer`.)
Refactor, clean up, etc.
Improve png2pnm.c:
* Add support for writing 16-bit raw PNM image files.
Fix and improve pnm2png.c:
* Add support for reading 16-bit raw PNM image files.
* Fix the parsing of arbitrarily long numeric strings.
In the parsing of PNM tokens, we can and we should avoid storing
more than one leading '0' in the token buffer. All valid (in-range)
numeric strings must fit in this limited-size buffer, regardless of
their actual length in the input file.
* Refactor the PNM parsing in order to make it more capable to handle
various kinds of input file errors.
* Remove the volatile qualifiers from all variable declarations.
Their original purpose was to appease old (and incorrect) warnings
issued by ancient optimizing compilers.
* Print a note about the program's lack of support for the PAM ("P7")
file format when the input is in this format.
* Add FIXME notes about the need to signal incorrect or incomplete
input files. (For png2pnm, this is done inside libpng.)
Raise the minimum required CMake version to 3.5.
Add the configuration option `PNGMINUS_USE_SYSTEM_PNG` for compiling
and linking with the system libpng library instead of the internal one.
Remove the old configuration option `PNGMINUS_USE_STATIC_LIBRARIES`.
When using the internal libpng (via `PNGMINUS_USE_SYSTEM_PNG=OFF`),
simply enforce static linking and produce single-file executables.
Rename the scripts "png2pnm.sh" (etc.) to "test_png2pnm.sh" (etc.),
to make it obvious that they are test drivers, not program launchers.
Add a .gitignore file for project-specific build and test artifacts.
This reverts the code to a variant of my old style of doing an 'fclose'
correctly and adds comments explaining why it is so difficult. Thanks
to @ihsinme for pointing out the error on github.com
Signed-off-by: John Bowler <jbowler@acm.org>
makepngs.sh relies on a Bash feature in one of its case statements,
";;&"; this should be made explicit in the shebang.
intgamma.sh declares a function in a manner which may fail in non-Bash
sh implementations, this patch uses the correct syntax.
Based on a patch by Roflcopter4:
https://github.com/joncampbell123/dosbox-x/pull/3850
Signed-off-by: Stephen Kitt <steve@sk2.org>
The <stdint.h> header is a standard C99 header, and a MIPS-specific
header, but it is not a standard C89 header. It should not be included
until ensuring that the code being compiled is MIPS-specific.
The old implementation of png_have_msa() caused a bus error,
if a word in /proc/cpuinfo was longer than 10 characters.
In the original implementation, `word[10]` was too short, and
`word[i++] = ch` caused a stack smash if the characters between
spaces were more than 10.
And also, fclose(f) should be called before leaving.
For example on loongson ls3a4000 cpu platform:
$ cat /proc/cpuinfo
system type : Generic Loongson64 System
machine : loongson,loongson64g-4core-ls7a
processor : 0
cpu model : ICT Loongson-3 V0.1 FPU V0.1
BogoMIPS : 3594.02
wait instruction : yes
microsecond timers : yes
tlb_entries : 2112
extra interrupt vector : no
hardware watchpoint : no
isa : mips1 mips2 mips3 mips4 mips5 mips32r1 mips32r2 mips64r1 mips64r2
ASEs implemented : vz msa loongson-mmi loongson-cam loongson-ext loongson-ext2
shadow register sets : 1
kscratch registers : 6
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
processor : 1
cpu model : ICT Loongson-3 V0.1 FPU V0.1
BogoMIPS : 3611.26
wait instruction : yes
microsecond timers : yes
tlb_entries : 2112
extra interrupt vector : no
hardware watchpoint : no
isa : mips1 mips2 mips3 mips4 mips5 mips32r1 mips32r2 mips64r1 mips64r2
ASEs implemented : vz msa loongson-mmi loongson-cam loongson-ext loongson-ext2
shadow register sets : 1
kscratch registers : 6
package : 0
core : 1
VCED exceptions : not available
VCEI exceptions : not available
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Sui Jingfeng <15330273260@189.cn>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Although the minimum required CMake version is 3.6, this policy will
only have effect under CMake 3.12 or newer.
Reported-by: Jacob Harding <54728054+jacobharding@users.noreply.github.com>
Remove the inclusion of the external module `CMakeParseArguments`.
Function argument parsing became a first-class feature in CMake 3.5.
Delete the function `find_symbol_prefix`. It is no longer used.
Use variables instead of strings in string operations where possible.
Prevent CMake from getting confused by string values that might be
accidentally identical to unrelated keywords.
Clean up spurious `.*` sequences in regex matching operations.
Rephrase a comment.
The PNG_FRAMEWORK option used to be off by default. It was possible to
turn it on, regardless of the underlying operating system, but doing so
outside of an Apple OS broke the libpng build.
PNG_FRAMEWORK is now on by default, conditionally defined on Apple
systems only, and it is ignored (without breaking the build) elsewhere.
Other minor changes have also been applied.
This reverts commit 9c1dc4d13dab823d6441d417546ebeee3994389b.
The new regex for Intel can match "x86_64", but it fails with "x86".
Moreover, the new regex for MIPS needs more testing on all MIPS ISAs.
Reported-by: Clinton Ingram <clinton.ingram@outlook.com>
Update the Travis CI matrix:
* Run ASan and UBSan unconditionally on FreeBSD and Linux, and
not at all on Mac.
* Remove the `CI_NO_TEST=1` runs from the environment column.
Update the AppVeyor CI matrix:
* Replace `CI_NO_TEST=1` with `CI_CMAKE_VARS=-DPNG_TESTS=0` when
testing Visual Studio on ARM64.
Also apply minor stylistic changes.
Rename `CI_HOST_ARCH` and `CI_HOST_SYSTEM`, to `CI_BUILD_ARCH` and
`CI_BUILD_SYSTEM`, following the nomenclature used by GNU Autotools.
Unfortunately, the word "host" has confusingly opposite meanings in
CMake (and Bazel, etc.) vs. Autotools (and Meson, etc.)
Remove `CI_TARGET_TRIPLET` and `CI_TARGET_ABI` (for now).
Introduce the function `ci_expr` as a fast and easy equivalent of
`expr >/dev/null`.
Rephrase the assertions using an implementation pattern that is more
expressive, yet (arguably) just as readable. Remove `ci_assert`.
Modify the main functions to display more useful information in case
of usage error.
1. Set `cmake_minimum_required` to 3.5
(see https://cmake.org/cmake/help/latest/release/3.27.html)
2. Specify the version of CMake project
3. Remove the redundant call to `cmake_policy`
4. Use `CMAKE_INSTALL_BINDIR` and `CMAKE_INSTALL_INCLUDEDIR`
5. Use private library linking for tools and test programs
6. Don't activate testing if it was not enabled
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
For the sake of consistency with a recent addition to the configure
script, the option name PNG_EXECUTABLES (introduced in libpng-1.6.38)
shall become PNG_TOOLS.
PNG_EXECUTABLES is still maintained as a deprecated option, allowing
the applications that use it to be built without modification, but a
deprecation warning will be issued.
Rename
--enable-png-tests/--disable-png-tests
--enable-png-tools/--disable-png-tools
to
--enable-tests/--disable-tests
--enable-tools/--disable-tools
respectively.
While the `PNG_` prefix is necessary in CMakeLists.txt, a corresponding
`--...-png-` option qualifier would be redundant in a configure script.
This PR adds two set of options to the configure script:
--enable-png-tests/--disable-png-tests
and
--enable-png-tools/--disable-png-tools
By using this feature, a user will be allowed to build only library if
needed, which will be useful on platforms not able to build the tools
and/or the tests.
This PR leaves the existing behaviour as default setting, by building
both the tools and the tests if the options are not used.
CMakeLists.txt already supports this feature with the options PNG_TESTS
and PNG_EXECUTABLES. After this commit, Autotools will provide the same
feature.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Introduce CI_TARGET_TRIPLET and CI_TARGET_ABI.
Rename CI_HOST_MACHINE and CI_TARGET_MACHINE, respectively, to
CI_HOST_ARCH and CI_TARGET_ARCH, following on the conventional
target triplet nomenclature.
Introduce CI_BUILD_SYSTEM and CI_BUILD_ARCH, following on the
GNU Autotools (host/build/target) practice and nomenclature.
Ensure that CI_TARGET_SYSTEM, CI_TARGET_ARCH and CI_TARGET_ABI
are all initialized when verifying a cross-platform build.
Work around an obscure CMake error by ensuring that CMake variables
(CMAKE_AR and CMAKE_RANLIB) are initialized to the full executable
paths of their CI_* equivalents (CI_AR and CI_RANLIB).
Implement other general-purpose improvements:
* Check all CI_NO_* variables in an arithmetic context, to allow
setting them explicitly to zero in external configurations.
* Label the assertions with descriptions of what's being asserted.
* Add more comments and tracing printouts.
Fix ci_verify_cmake.sh: sync up CI_BUILD_TO_INSTALL_RELDIR with
CI_INSTALL_DIR. (Oopsie!)
Replace slashes, backslashes and dots with underlines in system
names and machine hardware names. These names are now included in
the output directory naming scheme.
Replace CI_SYSTEM_NAME and CI_MACHINE_NAME with CI_HOST_SYSTEM and
CI_HOST_MACHINE, respectively.
Introduce CI_TARGET_SYSTEM and CI_TARGET_MACHINE, defaulting to
CI_HOST_SYSTEM and CI_HOST_MACHINE, respectively.
Use CI_TARGET_SYSTEM and CI_TARGET_MACHINE in the naming scheme of
target build and install directories, in order to allow concurrent
verification builds for multiple cross-platform targets.
Move the common declarations and initializations from ci_verify_*.sh
to ci.lib.sh, and update them as follows:
* Simplify the ci_ function names.
* Refactor the CI_ variable names:
- Add the new variable CI_TOPLEVEL_DIR.
- Rename the variables CI_SCRIPTNAME, CI_SCRIPTDIR, etc.,
to CI_SCRIPT_NAME, CI_SCRIPT_DIR, etc.
- Rename the variables CI_SRCDIR_FROM_BUILDDIR, etc., to
CI_BUILD_TO_SRC_RELDIR, etc.
* Add new functions inside ci.lib.sh:
- Replace ci_err with ci_err_usage, ci_err_fatal, ci_err_internal.
- Add the new functions ci_warn and ci_assert.
* Simplify the ci_ function names inside ci_verify_*.sh.
Fix a regression introduced in commit aeb26da4cb64c0e75c8d.
On an Illumos test machine, running the GCC compiler and the Solaris
link editor, the CMake build failed with the following error:
ld: fatal: unrecognized option '--version-script=/.../libpng.vers'
The fix consists in avoiding the use of CMAKE_SHARED_LIBRARY_C_FLAGS
in version script checks on Solaris.
Also clean up the surrounding code, as follows:
* Rename CMAKE_REQUIRED_FLAGS_SAVE to _SAVED_CMAKE_REQUIRED_FLAGS.
(The name of an internal variable should not begin with "CMAKE_".)
* Reformat the version script to optimize the vertical space.
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>
Add special handling of the PNG_INFO_tRNS flag to png_get_valid() to
not report a canceled tRNS chunk as valid.
Fix https://github.com/glennrp/libpng/issues/482
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Set the PNG_FREE_PCAL flag immediately after the allocation of the
first pCAL buffer, so that, if any one of the subsequent allocations
fail, all pCAL buffers still get deallocated by png_free_data.
Also reorder the initialization of other PNG_FREE_ flags (without
altering the semantics) to improve the overall consistency inside
the pngset.c module.
Co-authored-by: Philippe Antoine <contact@catenacyber.fr>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Users may opt to change the debug suffix, e.g., from "d" to "_debug".
Rather than making CMAKE_DEBUG_POSTFIX a cache variable (which is
an antipattern in CMake), we introduce a new cache variable, named
PNG_DEBUG_POSTFIX.
Suggested-by: Diego Barrios Romero <eldruin@gmail.com>
Redo commit 70fda1837d5de802ce5f7e04be239192b6a74d92, with a redesign.
Define the variables PNG_SHARED_OUTPUT_NAME and PNG_STATIC_OUTPUT_NAME
for the benefit of the OUTPUT_NAME target properties of, respectively,
the shared libpng build and the static libpng build. Fix and improve
not only Clang, but also other Windows toolchains, such as Embarcadero.
Rename the variable PNGLIB_SHARED_SOVERSION to PNG_ABI_VERSION.
The applicability of this variable, which is much wider than the old
name used to suggest, includes the definitions of PNG_*_OUTPUT_NAME.
Delete the confusingly-named variables PNGLIB_NAME and PNG_LIB_NAME,
and rename PNG_LIB_TARGETS to PNG_LIBRARY_TARGETS.
Set the macros _CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE,
for all compilers that use MSVC run-time library headers. Currently,
these compilers are MSVC and Clang/Windows.
Add or improve the comments that accompany user-serviceable variables
and options.
Co-authored-by: B. Scott Michel <scooter.phd@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
* Rename the target `png` to `png_shared`. The main targets are now
named `png_shared`, `png_static` and `png_framework`.
* Rename the function symbol_prefix() to find_symbol_prefix().
* Rename the prefix `S` to `_SYM` in the function create_symlink().
* Rewrite the precondition checks in the function create_symlink().
* Add precondition checks to the function generate_copy().
* Delete the vestigial property CLEAN_DIRECT_OUTPUT.
* Delete the variables PNG_LIB_NAME_STATIC and PNG_LIB_NAME_FRAMEWORK.
* Initialize and use PNG_LIB_TARGETS consistently as a list.
* Move all include() commands to the top of the file.
* Acknowledge a former contributor.
* Reformat.
This reverts commit 70fda1837d5de802ce5f7e04be239192b6a74d92.
Fixing Clang on Windows is important. However, in the previous fix,
the name of the compiled libpng library file was changed, incorrectly,
on all platforms except Windows. A proper fix will follow up.
Apply the following changes:
* Update CI_BUILDDIR and CI_INSTALLDIR to reflect the new script
names.
* Introduce CI_SRCDIR_FROM_BUILDDIR and CI_INSTALLDIR_FROM_BUILDDIR
to the cmake build, to ensure that the Windows tools can handle
native Windows paths correctly when executed via Bash-on-Windows.
* Stop guessing and using CI_SRCDIR_NATIVE and CI_INSTALLDIR_NATIVE
in the cmake build, since we now have a better solution.
* Show the ninja program version in ninja-based cmake builds.
* Move the cleanup of previous builds into separate functions, and
do it in a cleaner manner. No pun intended.
Fix a build error that occurs with the Ninja code generator and the
Clang compiler on Windows:
ninja: error: build.ninja: multiple rules generate png16.lib
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Building the version script test executable may fail in the link step
with GNU ld as linker like this:
ld: final link failed: Nonrepresentable section on output
Building the test excutable with CMAKE_SHARED_LIBRARY_C_FLAGS makes the
test succeed with GNU ld since this adds -fpic/-fPIC.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Fix the issue of a
clang: error: no such file or directory: 'x86_64'
error on building universal binaries on macOS.
It is also necessary to specify:
-DCMAKE_C_FLAGS="-DPNG_ARM_NEON_OPT=0"
Example CMake command:
cmake -S libpng \
-B build_libpng \
-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" \
-DCMAKE_C_FLAGS="-DPNG_ARM_NEON_OPT=0"
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Fix autodetection and use of the cygpath executable on Windows.
Add a new variable CI_CMAKE_TOOLCHAIN_FILE to ci_verify_cmake.sh.
This should help in future cross-platform testing.
Remove the implicit initialization of CI_CC, CI_LD and CI_LIBS from
ci_verify_makefiles.sh. This should help the testing of default values
of their respective make variables (CC, LD and LIBS).
Give the CI scripts new names that better reflect what they do, and
make room for activities such as linting or dependency installation:
* Rename ci_autotools.sh to ci_verify_configure.sh.
* Rename ci_cmake.sh to ci_verify_cmake.sh.
* Rename ci_legacy.sh to ci_verify_makefiles.sh.
Also rename CI_LEGACY_MAKEFILES to CI_MAKEFILES.
Update the config files for Travis CI and AppVeyor CI accordingly.
From libpng-1.5.0 onwards, the private libpng functions are no longer
accessible to the libpng users, and the content of libpngpf(3) is no
longer relevant.
Update links, introducing the new canonical location of the libpng
source repository:
https://github.com/pnggroup/libpng
Remove all remaining "last changed" version info from source comments.
(The version control system maintains this information automatically.)
Delete the trailing whitespace characters.
With the caveat that oss-fuzz needs a full sync with upstream, here
are the changes applied to our old copy:
* Add a missing #include directive.
* Remove the "last changed" version info.
* Clean up the trailing whitespace.
Co-authored-by: Ilya Yegorov <hkctkuy@gmail.com>
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Rename contrib/tools/chkfmt to contrib/tools/chkfmt.sh; refactor:
* Increase the max line length for contrib/**/*.[ch] from 96 to 100.
* Set the max line length for ci_*.sh to 100.
* Use `basename $0` instead of the hard-coded script name.
* Update comments.
Remove contrib/tools/reindent. For automated code formatting, including
indentation, we need a robust solution.
Add an empty line after the hashbang line in all scripts.
Remove the "last changed" version info from comment headers.
(The version control system maintains this information automatically.)
Import Chromium commit
e87a029871
Add the author to the list of libpng contributing authors.
Portions from the original commit message follow:
***
A recent change to libpng [1] (included in Chromium with the recent
libpng update [2]) turns chunks that are bigger than
PNG_USER_CHUNK_MALLOC_MAX into failures. Although this matches the
intent of PNG_USER_CHUNK_MALLOC_MAX, it also causes images which used to
be viewable in Chromium to fail. Changing to a benign error allows us to
display these images once again. Though it means we do allow libpng to
allocate more than PNG_USER_CHUNK_MALLOC_MAX, it matches the behavior
prior to [2] (when we were using 1.6.22), and it does not regress
crbug.com/117369
[1] 347538efbd
[2] f82653a473
***
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=827754
Co-authored-by: Leon Scroggins III <scroggo@google.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Following up on the previous commit by Martin Storsjö:
If the availability of ARM Neon is not only known at compile time,
but also expected by the compiler's target architecture, there should
be no further need for a run-time check. In fact, such a check would
be counter-productive.
This matches the configure script - unless the user has requested
anything, no hardware optimizations are autoenabled.
Defaulting to "check" is brittle (that configuration is deprecated
and poorly supported) - and for configurations where it would
make sense (where NEON isn't universally enabled in the compiler)
it didn't end up setting ARM_NEON_OPT to 1 in pnglibconf.h anyway.
This fixes default builds with cmake for iOS and Windows on armv7,
where NEON is universally available (but there's no runtime check
implemented) - but actually using NEON on this architecture
requires explicitly opting in to it when configuring, just like
with the configure script.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
In most of the legacy makefiles (with only a few notable exceptions
such as makefile.linux), the "install" targets have been broken since
libpng-1.5.0beta01. Specifically, the "install-shared" targets produced
incorrect library names, due to a missing symbol in the definition of
the LIBSOREL macro.
Rather than correcting this long-standing and long-untested error, we
decided to remove the support for "make install" altogether, from all
legacy makefiles. Further use of "make install", "make install-static"
or "make install-shared" will fail with an error message.
Going forward, the only tested and supported manners to install libpng
shall be the conventional build and install procedures driven by the
configure script or by the CMake file.
Considering that the EXIF support is part of the core libpng library
(which excludes scripts, tests, and other independent programs), its
contributors should be acknowledged in the AUTHORS file.
The check should fail if the EXIF byte-order header doesn't start with
a correct character, or if the two heading characters aren't identical.
Rewrite the check to make the code logic easier to follow.
The second call to png_write_eXIf should not have been removed.
The first call to png_write_eXIf is for writing the eXIf chunk that is
positioned before IDAT, while the second call is for writing the eXIf
chunk that is positioned after IDAT.
TODO:
Implement a correct fix which consists in ensuring that there are no
eXIf chunks simultaneously before and after IDAT.
This reverts commit cd03aaf7bf0e0c748b8c6cb34a56b402b40d61d0.
Fix the legacy makefile builds on ARM, MIPS and PowerPC, where
hardware-optimized compilation was enabled by default in the generic
source files, but without including the machine-specific source files.
Delete scripts/makefile.linux-opt.
Considering that "-Wextra" is a more descriptive alternative to "-W",
and that "-Wundef" is a highly useful warning option that has been
available in ancient versions of gcc (version 2.x), we replace all
occurrences of "-W -Wall" with "-Wall -Wextra -Wundef".
Also clean up the makefiles.
The console logs produced by these scripts should be easy to follow,
especially on CI bots.
Delete the unnecessary macros ECHO and SED.
Add a new macro MV_F (for "mv -f"), alongside RM_F (for "rm -f").
The hIST chunks, used for storing image histograms, contain arrays of
16-bit unsigned integers, and the chunk size is expected to be an even
number. Raise a png_chunk_benign_error() if a hIST chunk fails to meet
this expectation.
Reported-by: Eugene Kliuchnikov <eustas@google.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).
ARM Neon is expected to be unconditionally available on ARM64.
Issue an #error if PNG_ARM_NEON_CHECK_SUPPORTED is defined on an
ARM64-based platform.
For the plain ARM platforms where ARM Neon checking is not yet
implemented, issue a slightly more descriptive #error, including
a suggested course of action.
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.
This leak was discovered by OSS-Fuzz.
The old structure of the code was along the lines of:
allocate trans_alpha;
if (problem) {
// Jumps away from this function
png_warning("tRNS chunk has out-of-range samples for bit_depth");
}
mark trans_alpha as to-free;
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This bug was found by FUTAG, a program for generating automated
fuzz-targets of libraries.
TODO:
Implement a safe function, alternative to png_convert_from_time_t,
which takes a png_ptr argument and raises a png_error if the time_t
argument is invalid.
Reported-by: Tran Chi Thien <thientc@ispras.ru>
Reported-by: Shamil Kurmangaleev <kursh@ispras.ru>
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.
This makefile is based on makefile.vcwin32, but includes Neon
intrinsic optimization.
Co-authored-by: Gabor Kertesz <gabor.kertesz@linaro.org>
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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.
The ld version script should not be generated on Android.
Co-authored-by: Volker Krause <vkrause@kde.org>
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The issue is that, by default, Git for Windows checks out text files
with CRLF line endings. This is a problem for awk, which is expecting
Unix-style LF line endings. When cloning on Windows and attempting to
compile on WSL, Mingw or Cygwin, there may be an error from awk.
The fix is to leverage CMake's ability to configure a file and perform
EOL conversions. We copy the awk scripts from the source directory to
the build directory. This portable method ensures they have LF endings,
and the build logic is updated to use the build directory version.
Intentionally avoiding .gitattributes to avoid setting precedent.
Co-authored-by: Christopher Sean Morrison <brlcad@gmail.com>
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Generated files depend on other generated files, and this previously
resulted in the same custom command output being a dependency of
multiple other custom commands without a shared custom targets.
Adds a top-level target for each generated file and ensures that
commands that depend on generated files also depend on the corresponding
custom targets.
Per CMake documentation:
> Do not list the output in more than one independent target
> that may build in parallel or the two instances of the rule
> may conflict (instead use add_custom_target to drive the command
> and make the other targets depend on that one).
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Apply the following changes:
* Add FreeBSD (besides Linux and Mac) to the Travis CI testing.
* Use cc instead of clang for Xcode in the Travis CI testing.
* Upgrade the Windows test image from Visual Studio 2019 to
Visual Studio 2022 for AppVeyor CI.
Apply the following changes:
* Set CI_CMAKE_GENERATOR to "Ninja" by default in ci_cmake.sh.
* Set CI_CC to cc by default in ci_autotools.sh.
* Rename CI_SYSNAME to CI_SYSTEM_NAME; add CI_MACHINE_NAME.
* Apply other minor changes and fixes.
Implement the following updates:
* Add CI_SYSNAME and set it to `uname -s`.
* Set the default CI_CC value to "clang" on all BSD systems.
* Replace CI_SRCDIR_REL_BUILDDIR and CI_INSTALLDIR_REL_BUILDDIR
with CI_SRCDIR_NATIVE and CI_INSTALLDIR_NATIVE.
The former variables were hard-coded and error-prone; the new
variables are computed and safe to use.
The second call to write_eXIf doesn't check whether the first call
succeeded; no other chunks except tIME and the text chunks seem to be
doubled like this.
The second call causes the eXIf chunk to incorrectly be written twice.
pngimage.c:
Initialize sig_bits on a NOTREACHED path to avoid warnings about using
uninitialized variables.
pngstest.c:
Enlarge buffers and fix signedness to avoid legitimate warnings about
potential buffer overflows.
pngunknown.c:
pngvalid.c:
Use NULL instead of 0 for pointers and apply other style fixes.
makepng.c:
tarith.c:
Apply various style fixes.
Also remove the "last changed" version info from source comments.
The version control system maintains this information automatically.
The Unix paths in Bash do not mix well with the Windows paths in CMake.
The uppercase and the lowercase environment variables do not mix well
in MSBuild. Et cetera.
On AppVeyor CI, verification of Windows builds with the Visual Studio
toolchain used to work, perhaps due to one or more lucky coincidences,
but it stopped working after an upgrade on the AppVeyor CI site.
Update ci_cmake.sh as follows:
* Use POSIX commands like "mkdir" and "rm" instead of CMake commands
like "make_directory" and "remove_directory".
* Avoid using absolute paths in the CMake command line; use relative
paths that are accessible from both Bash and Windows.
* Clean up incidental mixtures of Windows and Bash-on-Windows
environment variables like {$TEMP,$Temp,$temp} and {$TMP,$Tmp,$tmp}.
For ci_autotools.sh, customize CPP, CPPFLAGS, AR, RANLIB, LD, LDFLAGS
via CI_CPP, CI_CPP_FLAGS, CI_AR, CI_RANLIB, CI_LD, CI_LD_FLAGS.
For ci_cmake.sh and ci_legacy.sh, customize AR, AR_RC and RANLIB via
CI_AR and CI_RANLIB.
Rewrite portions of ci_legacy.sh to match the style of ci_cmake.sh.
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.
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.
Delete the files that are unused, redundant, or fundamentally broken:
def.c, makefile.bor, makefile.knr, makefile.msc, makefile.solaris-x86,
makefile.tc3
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.
pngpread.c and use the sequential png_handle_tEXt, etc., in pngrutil.c;
now that png_ptr->buffer is inaccessible to applications, the special
handling is no longer useful.
Fixed bug with png_handle_hIST with odd chunk length (Frank Busse).
"PNG_" to begin any of their own symbols.
Fixed mistake in the descriptions of user read_transform and write_transform
function prototypes in the manual. The row_info struct is png_row_infop.
reflect more accurately what it actually does. At the same time, renamed
the PNG_DITHER_[RED,GREEN_BLUE]_BITS macros to
PNG_QUANTIZE_[RED,GREEN,BLUE]_BITS.
when PNG_WRITE_SUPPORTED is not enabled. There was no good reason
for this restriction, and PNG readers can gain a speed benefit in
reading large iCCP chunks by increasing png_ptr->zbuf_size via
these functions.
about deprecated function use and deprecated structure access unless the
user defines PNG_PEDANTIC_WARNINGS. Added "#define PNG_NO_PEDANTIC_WARNINGS"
in the libpng source files. Removed "-DPNG_CONFIGURE_LIBPNG" from the
makefiles and projects since the warnings no longer depend on this.
Revised iTXt support. To ensure binary compatibility with
previous versions, the "lang" and "lang_key" members will be assumed
to be omitted from versions prior to 1.2.41beta11 whenever there is a
library mismatch.
To ensure binary compatibility with
previous versions, the "lang" and "lang_key" members will be assumed
to be omitted from previous versions unless the current libpng
version was built with PNG_iTXt_SUPPORTED (which is otherwise no
longer necessary to gain iTXt support), as a signal that the user has
been building previous versions with PNG_iTXt_SUPPORTED as well.
outside of the PNG_READ|WRITE_ANCILLARY_CHUNK_SUPPORTED macros and
updated CHANGES and ANNOUNCE. The definitions were actually relocated
in the previous commit but I forgot to mention it.
to PNG_HANDLE_AS_UNKNOWN to make it possible to build a libpng that can
use the png_set_keep_unknown_chunks() mechanism to ignore unused chunks
without having to save unknown chunks.
sig_bit was not declared in write_png() and was used differently from
sig_bit in read_png(), as reported by Vincent Torri. This update changes
sig_bit to sig_bit_p in read_png() and declares sig_bit in write_png().
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
