in the code the number of elements in an array is calculated using
sizeof. This generates a compile time constant of type (size_t) which
is then typically assigned to an (unsigned int) or (int). Some versions
of GCC on 64-bit systems warn about the apparent narrowing, even though
the same compiler does apparently generate the correct, in-range,
numeric constant. This adds appropriate, safe, casts to make the
warnings go away.
management system (CMS). In practice it is not possible to obtain cHRM
information reliably using just the end-point tags because they do not exist
in the vast majority of profiles. Instead it is necessary to run the endpoints
through the ICC colorimetric intent transform (as described in the v4
spec). Since this is likely to be too much code inside libpng for too
little gain (it implies a fairly complete CMS implementation) the code
has been changed to allow an external CMS to be used. This code is
temporarily disabled until a suitable set of test cases using one or more
external CMS implementations have been implemented.
fixed Cygwin+MSVC build errors. The ICC profile handling now includes more
checking. Several errors that caused rejection of the profile are now
handled with a warning in such a way that the invalid profiles will be
read by default in release (but not pre-RC) builds but will not be
written by default. The easy part of handling a cHRM chunk is written,
where the ICC profile contains the required data. The more difficult
part plus guessing a gAMA value requires code to pass selected RGB values
through the profile.
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_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.
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.
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.
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.
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.
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.
