contrib/libtests/makepng: corrected 'rgb' and 'gray' cases.  profile_error
    messages could be truncated; made a correct buffer size calculation and
    adjusted pngerror.c appropriately. png_icc_check_* checking improved;
    changed the functions to receive the correct color type of the PNG on read
    or write and check that it matches the color space of the profile (despite
    what the comments said before, there is danger in assuming the app will
    cope correctly with an RGB profile on a grayscale image and, since it
    violates the PNG spec, allowing it is certain to produce inconsistent
    app behavior and might even cause app crashes.) Check that profiles
    contain the tags needed to process the PNG (tags all required by the ICC
    spec). Removed unused PNG_STATIC from pngpriv.h.

png_handle_unknown() when SAVE support is absent.  Moved the shell test
scripts for contrib/libtests from the libpng top directory to contrib/libtests.
png_handle_unknown() must always read or skip the chunk, if
SAVE_UNKNOWN_CHUNKS is turned off *and* the application does not set
a user callback an unknown chunk will not be read, leading to a read
error, which was revealed by the "tunknown" test.

libpng handling of unknown chunks other than vpAg and sTER (including
unsafe-to-copy chunks which were dropped before) and eliminates the
repositioning of vpAg and sTER in pngtest.png by changing pngtest.png
(so the chunks are where libpng would put them).

png_set_keep_unknown_chunks() to be turned off if not required and causes
both read and write to behave appropriately (on read this is only possible
if the user callback is used to handle unknown chunks).  The change
also removes the support for storing unknown chunks in the info_struct
if the only unknown handling enabled is via the callback, allowing libpng
to be configured with callback reading and none of the unnecessary code.

control of the unknown handling, corrects the pre-existing bug where
the per-chunk 'keep' setting is ignored and makes it possible to skip
IDAT chunks in the sequential reader (broken in earlier 1.6 versions).
There is a new test program, test-unknown.c, which is a work in progress
(not currently part of the test suite).  Comments in the header files now
explain how the unknown handling works.

Both object to the split initialization of num_chunks.

and png_memcmp() macros.

png_memset(), png_memcpy(), and png_memcmp() macros.

support.  Now "make check" will succeed even if libpng is compiled with
-DPNG_NO_READ or -DPNG_NO_WRITE.  The tests performed are reduced, but the
basic reading and writing of a PNG file is always tested by one or more of
the tests.

except in pngtest.c and example.c where these macros are not visible.

errors) and cause it not to fail at the comparison step if libpng lacks support
for writing chunks that it reads from the input (currently only implemented
for compressed text chunks).

This is a small function, but avoiding compiling it also avoids needing
to link with "-lm" unnecessarily.

builds.  Restored png_get_channels() to WRITE-only builds.

issues with 1.12 and insisting on anything less would allow 1.12 to be used.

patch; they are needed by png_set_IHDR() for both read and write.  Fix
some ifdefs that caused the contrib/pngminim/ applications to not compile.

on read and write.  In libpng 1.6 the two cases can be distinguished and
considerable code cleanup, and extra error checking, is possible.  This
makes calls on the write side that have no effect be ignored with a
png_app_error(), which can be disabled in the app using
png_set_benign_errors(), and removes the spurious use of usr_channels
on the read side.

a consistent style for (sizeof type) and (sizeof (array))

of strcpy() was accidentally re-introduced in libpng16; this change replaces
it with strncpy().

Because of the changes to support symbol prefixing PNG_INTERNAL_FUNCTION
declares floating point APIs during libpng builds even if they are completely
disabled. This requires the png floating point types (png_double*) to be
declared even though the functions are never actually defined.  This
change provides a dummy definition so that the declarations work, yet any
implementation will fail to compile because of an incomplete type.

comments.  It has apparently been wrong since libpng-1.0.1c (confusing
use of a 1D and a 2D array for the image source).

They have not been exported to applications since libpng12.

(This is probably unnecessary because it's inside a __GNUC__ block.)

This has been missing since the feature was introduced in libpng-1.6.0beta04.