Both object to the split initialization of num_chunks.

and png_memcmp() macros.

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

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.

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

ignore all unknown chunks and all known chunks except for IHDR, PLTE, tRNS,
IDAT, and IEND.  Previously it only meant ignore all unknown chunks, the
same as num_chunks == 0. Revised png_image_skip_unused_chunks() to
provide a list of chunks to be processed instead of a list of chunks to
ignore.  Revised contrib/gregbook/readpng2.c accordingly.

load iCCP

when writing.

palette index.

functions [rw]util.c.  A new shared keyword check routine was also added
and the 'zbuf' is no longer allocated on progressive read.  It is now
possible to call png_inflate() incrementally.

Relocated palette-index checking function from pngrutil.c to pngtrans.c

those uses of png_memcpy that were doing a simple assignment to assignments
(all those cases where the thing being copied is a non-array C L-value.)
Added some error checking to png_set_*() routines and removed the
reference to the non-exported function png_memcpy() from example.c. Fixed
the Visual C 64-bit build - it requires jmp_buf to be aligned, but it had
become misaligned.

 Because these APIs store to the png_info they can take a
 png_const_structrp now that the error routines also accept
 one of these.

Added new "png_structrp" typedef. Because of the
way libpng works both png_info and png_struct are always accessed via a
single pointer.  This means adding C99 'restrict' to the pointer gives
the compiler some opportunity to optimize the code.  This change allows that.

changes alter how the tricky allocation of the initial png_struct and png_info
structures are handled. png_info is now handled in pretty much the same
way as everything else, except that the allocations handle NULL return
silently.  png_struct is changed in a similar way on allocation and on
deallocation a 'safety' error handler is put in place (which should never
be required).  The error handler itself is changed to permit mismatches
in the application and libpng error buffer size; however, this means a
silent change to the API to return the jmp_buf if the size doesn't match
the size from the libpng compilation; libpng now allocates the memory and
this may fail.  Overall these changes result in slight code size
reductions; however, this is a reduction in code that is always executed
so is particularly valuable.  Overall on a 64-bit system the libpng DLL
decreases in code size by 1733 bytes.  pngerror.o increases in size by
about 465 bytes because of the new functionality.

and png_convert_to_rfc1123(). (Frank Busse).

The 16-bit cases still use "L" as we don't have a 16-bit test system.

to conditions where types that are 32 bits in the GCC 32-bit
world (uLong and png_size_t) become 64 bits in the 64-bit
world.  This produces potential truncation errors which the
compiler correctly flags.

and fixed spelling (truely -> truly) in comments.

and fix some other small typos.