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.
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.
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.
These fixes attend to most of the errors revealed in pngvalid, however doing
the gamma work twice results in inaccuracies that can't be easily fixed.
There is now a warning in the code if this is going to happen.
1.5.3beta06
Also removed a spurious (totally unused and confusing) member from png_info.
The palette expand optimization prevented expansion to an intermediate RGBA
form if tRNS was present but alpha was marked to be stripped; this exposed
a check for tRNS in png_do_expand_palette() which is inconsistent with the
code elsewhere in libpng.
wrong (high by one) 25% of the time. Dividing by 257 with rounding is
wrong in 128 out of 65536 cases. Getting the right answer all the time
without division is easy.
This problem is present in 1.5.2; if png_set_background is called with
need_expand false and the matching 16 bit color libpng erroneously just treats
it as an 8-bit color because of where png_do_expand_16 is in the transform
list. This simple fix reduces the supplied colour to 8 bits, so it gets
smashed, but this is better than the current behavior.
