[pull] libpng16 from pnggroup:libpng16 #70
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
`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.
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.
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.
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.
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`.
This fixes commit dddaf0c. The way to reliably `find` executable files is different on BSD, Mac and Linux, unfortunately.
This fixes commit 4edbb4d. During the move of CMake scripts to the scripts/cmake/ subdirectory, some of the workflows have been broken. Signed-off-by: Cosmin Truta <[email protected]>
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.
Add nawk to the list of AWK-processing programs that are known to work, and show the search result in the CMake log.
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.
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.
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 <[email protected]>
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.
The release tags are redundant in the CI process. It is the main branch that is always verified.
This fixes the bug #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 <[email protected]>
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 <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
In the previous commit 9e53875 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.
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.
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.
Signed-off-by: Cosmin Truta <[email protected]>
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 <[email protected]> Signed-off-by: John Bowler <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
Apart from the png.h change, these files are machine-generated. Reviewed-by: Cosmin Truta <[email protected]> Signed-off-by: John Bowler <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
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.
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 92e8581, 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 <[email protected]> Signed-off-by: John Bowler <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
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.
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 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)
This is a major change required by the new PNGv3 colour chunk precedence rules. It **does not** change the libpng API (png.h) however it changes the following handling of PNG files: IFF the PNG file contains colour space information it changes from the libpng v3 behaviour to the now compulsory PNG v3 behaviour: 1) libpng no longer invalidates colour space chunks because they are inconsistent. 2) libpng no longer responds to the "png_get_" APIs positively if they are not present in the PNG but can be deduced from the colour space chunks that are present.
The 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 <[email protected]>
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 <[email protected]> Signed-off-by: John Bowler <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
This is a regression of commit 2519a03 "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 <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
This is a regression of commit a8242dd "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 <[email protected]> Reviewed-by: Cosmin Truta <[email protected]> Signed-off-by: John Bowler <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
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 <[email protected]>
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 <[email protected]> Signed-off-by: John Bowler <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
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.
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.
…pport 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 e936211 from branch 'libpng18'. Reviewed-by: John Bowler <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
…ocumentation 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 c63c546 from branch 'libpng18'. Reviewed-by: John Bowler <[email protected]> Signed-off-by: Cosmin Truta <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )