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>
