inflate. This works round a bug introduced in 1.5.4 where compressed ancillary
chunks could end up with a too-small windowBits value in the deflate
header.
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.
read code now claims and releases png_ptr->zstream, like the write code.
The bug whereby the progressive reader failed to release the zstream
is now fixed, all initialization is delayed, and the code checks for
changed parameters on deflate rather than always calling
deflatedEnd/deflateInit.
problems. This is an intermediate check-in that solves the immediate problems
and introduces one performance improvement (avoiding a copy via png_ptr->zbuf.)
Further changes will be made to make ICC profile handling more secure.
compiler issues slightly different warnings from those issued by the
current vesions of GCC. This eliminates those warnings by
adding/removing casts and small code rewrites.
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.
changes the 'Paeth' reconstruction function to improve the GCC code
generation on x86. The changes are only part of the suggested ones;
just the changes that definitely improve speed and remain simple.
The changes also slightly increase the clarity of the code. In a
in pngmem.c; pngvalid would attempt to call png_error() if the allocation
of a png_struct or png_info failed. This would probably have led to a
crash. The pngmem.c implementation of png_malloc() included a cast
to png_size_t which would fail on large allocations on 16-bit systems.
The logical shift fix for Microsoft Visual C is required by other compilers,
so this enables that fix for all compilers when using compile-time constants.
Under MSYS 'byte' is a name declared in a system header file, so we
changed the name of a local variable to avoid the warnings that result.
is not byte aligned, while reading. Prior to libpng-1.5.6 libpng would
overwrite the end of the image if the row width is not an exact multiple
of 8 bits and the image is not interlaced.
small percentage for 16-bit and 32-bit pixels in the typical case where the
output row buffers are appropriately aligned. The optimization was not
previously possible because the png_struct buffer was always misaligned.
caused by a bug in the code that attempted to align it; the code needs to
subtract one from the pointer to take account of the filter byte prepended to
each row.
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.
recognize the file extension, so it always compiles with C++ rules. Made minor
changes to pngrutil.c to cast results where C++ expects it but C does not.
