blob: 07b4ab1db8fb7f1674151d9e8654d91807867ae1 [file] [log] [blame]
Known bugs and suggested enhancements in libpng-1.0.6
1. April 24, 2000 -- BUG -- binary incompatibility
Libpng-1.0.6 is binary incompatible with old applications that
allocate the png_struct and png_info structures themselves instead
of using png_create_*(). They do not allocate enough space for
the structures because they have an incorrect notion of
sizeof(png_struct) and sizeof(png_info). Although such applications
should be considered broken rather than considering libpng to be broken,
they are numerous and include products of the PNG group, such
as gif2png and pnmtopng-2.36 (pnmtopng-2.37 is OK), so libpng will
be fixed in version 1.0.7 to work around this problem.
Applications that use png_create_*() instead of png_ptr=malloc(...)
are immune to this problem.
STATUS: Fixed in libpng-1.0.6ad, libpng-1.0.6j, and patch-d
which are currently being tested by the PNG group.
The fix necessarily reintroduces a binary incompatibility with any
application that makes direct access to the png_info and
png_struct members that deal with the pCAL chunk, palette_lookup,
dither_index, time_buffer, or weighted filtering, i.e., any members
coming after the new "free_me" member of either structure. It
is believed that applications affected by this reintroduced binary
incompatibility are rare (none are known to the PNG group). An
effective workaround for this and the next bug is to recompile the
old applications with the installed version of libpng.
2. April 23, 2000 -- BUG -- binary incompatibility
Libpng-1.0.6 introduced binary incompatibility for applications that
make direct access to members of the png_struct and png_info structures,
due to the insertion of the free_me member ahead of some previously
existing members.
Applications that use png_set_*(), png_get_*() are immune to this
problem, but people are still to this day writing applications that
make ill-advised direct access to members of the png_struct and
png_info structures, so libpng-1.0.6 will be patched to work around
this problem.
STATUS: Fixed in libpng-1.0.6j and patch-d, which are currently being
tested by the PNG group. Users can work around the problem without
patching libpng by recompiling their applications.
3. April 15, 2000 -- BUG -- pnggccrd.c
If PNG_NO_GLOBAL_ARRAYS is defined, pnggccrd.c will not compile.
STATUS: Fixed in libpng-1.0.6g
4. April 1, 2000 -- BUG
Under some circumstances old applications that make direct access to
the info_ptr->text and its members might free the same memory that
is also free'ed by libpng during the png_destroy_struct process.
Fixed in libpng-1.0.6-patch-c and libpng-1.0.6d. The PNG_FREE_TEXT flag
bit in info_ptr->free_me is now checked to make sure libpng is responsible
for freeing the memory.
5. April 1, 2000 -- BUG
The non-ISO-C "strdup()" function is used in png.c
STATUS: The function has been simplified and no longer uses strdup()
in libpng-1.0.6-patch-c and libpng-1.0.6d.
6. March 24, 2000 -- BUG
The png_set_rgb_to_gray_fixed() function is setting incorrect weighting
factors.
STATUS: Fixed in libpng-1.0.6-patch-b and libpng-1.0.6d.
7. March 22, 2000 -- BUG
There are some printf() and fprintf() statements active in pngwutil.c
when PNG_NO_STDIO and PNG_sCAL_SUPPORTED are both defined.
STATUS: Fixed in libpng-1.0.6-patch-a and libpng-1.0.6d. The strcpy()
function is used instead.
8. March 22, 2000 -- BUG
The length of the iCCP chunk data is calculated incorrectly; because
it can contain zeroes, strlen() doesn't work.
STATUS: Fixed in libpng-1.0.6-patch-a and libpng-1.0.6d by adding a
data_length parameter to the png_decompress_chunk() function.
9. March 15, 1998 -- OPTIMIZATION -- Kevin Bracey
Loops need to be optimized everywhere
Make them count down instead of up -- Kevin Bracey
Optimizing compilers don't need this, and making
the change would be error prone -- Tom Lane, Glenn R-P
Question whether i-- or --i is better.
STATUS: Under investigation, postponed until after
libpng-1.1.0. About 160 loops will be turned around
in libpng-1.1.Nn, for testing.
10. July 4, 1998 -- ENHANCEMENT -- Glenn R-P
libpng-1.0.5 and earlier transform colors to gamma=1.0 space for
merging with background, and then back to the image's gamma. The
bit_depth of the intermediate (gamma=1.0) representation is probably
not sufficient. In the typical gamma=1/2.2 situation, the linear
pixels need about 4 more bits than the gamma-encoded ones, to avoid
loss of precision. A similar situation exists with the rgb_to_gray
operation.
STATUS: under development.
11. September 1999 -- ENHANCEMENT --
It should be possible to use libpng without floating-point aritmetic.
STATUS: Under investigation, implementation postponed until after
libpng-1.0.6. The application interface will change because replacements
for the png_set_gAMA(), png_set_cHRM(), and corresponding png_get_()
functions will be needed.
Much of this was completed in libpng-1.0.6, but gamma compensation
is not yet done in fixed-point arithmetic.