POINTER_INDEXING was a build configuration option that we maintained
in order to work around a gcc 2.7.2.2 code generation bug (circa 1997).
This provided array-indexing fallback loops in `png_write_PLTE` and
`png_write_sPLT`.
Unfortunately, the fallback paths were effectively untested dead code
in every default build, and have been a recurring source of latent bugs.
(See commit 48800443eb in pnggroup/libpng#801 and commit f27592a0cd in
libpng 1.5.2rc02).
No compiler in current use requires this accommodation.
The purpose of this feature was to optionally prepend standardized
numbers to error and warning messages. The ERROR_NUMBERS feature was
first drafted in libpng-1.2.0 and further developed in libpng-1.4.0;
and yet, it was always disabled by default, and never completed.
In the light of a recent report concerning the security hazards arising
from enabling this code in custom libpng builds, we think it's best to
simply remove all the code written to support this feature.
Reported-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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`.
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>
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>
Considering that pnglibconf is a whole mini-system for configuring and
building libpng, it should be placed in its own dedicated subdirectory.
Any future additions, including tests and documentation, should go into
this subdirectory.
One exception: pnglibconf.h.prebuilt is moved to the top-level source
directory, where pnglibconf.h would be. This follows the organization
pattern typically used with the "*.in" files, for example.
All references to the pnglibconf artifacts, found in machine-readable
code and in human-readable comments, are updated accordingly.
In order to make ABI compatibility guarantees about the Windows DLL,
we had to keep maintaining the API ordinals consistently. As we are
now designing a fresh new ABI, we use this opportunity to stop using
ordinals altogether.
Exporting API functions by ordinal numbers instead of names was a
necessity in the early (16-bit) versions of Windows, by design, to
minimize the memory requirements. Although using ordinals was still
possible in all subsequent versions of Windows, it was no longer
necessary from the 32-bit versions of Windows onwards.
The libpng DLL will still have ordinals, assigned arbitrarily, but
the dynamic linking of applications to this DLL will be done by name.
(The applications that use the zlib DLL operate in the same manner.)
Reviewed-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Apply the stylishness of the One True Brace Style to scripts/*.awk.
Also rename the debug variable, and tidy up comments and whitespace.
TODO:
Run this task during linting, e.g., by using "prettier" with a plugin.
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.
