zlib-1.2.1 valgrind warnings

[Anthony J Bybell]

These might have impact on function. I don't have time to analyze the
sourcecode this very moment.

-t

==31634== Conditional jump or move depends on uninitialised value(s)
==31634== at 0x805B1C2: _tr_flush_block (trees.c:934)
==31634== by 0x8058588: deflate_slow (deflate.c:1499)
==31634== by 0x8056660: deflate (deflate.c:630)
==31634== by 0x80514C9: do_flush (gzio.c:732)

==31634== Conditional jump or move depends on uninitialised value(s)
==31634== at 0x8056FB8: longest_match (deflate.c:952)
==31634== by 0x8057F6D: deflate_slow (deflate.c:1422)
==31634== by 0x8056660: deflate (deflate.c:630)
==31634== by 0x80514C9: do_flush (gzio.c:732)

==31634== Conditional jump or move depends on uninitialised value(s)
==31634== at 0x8057084: longest_match (deflate.c:966)
==31634== by 0x8057F6D: deflate_slow (deflate.c:1422)
==31634== by 0x8056660: deflate (deflate.c:630)
==31634== by 0x80514C9: do_flush (gzio.c:732)

[Mark Adler]

byb...@rocketmail.com (Anthony J Bybell) wrote in message news:<30cb2c4.04022...@posting.google.com>...

> These might have impact on function.

They don't. Comments below.

> ==31634== at 0x8056FB8: longest_match (deflate.c:952)

> ==31634== at 0x8057084: longest_match (deflate.c:966)

Those are intentional. For speed, a string comparison loop checks for
the end of the string only every eight byte comparisons, and so can go
past the end. The comparisons are within allocated memory, and
matches past the end are not used. So there is no impact on function.

> ==31634== at 0x805B1C2: _tr_flush_block (trees.c:934)

This one was interesting. I found that the data_type variable in the
zlib stream structure has never been set in all these years that zlib
has been out there, and no one has ever noticed! zlib.h says:
"deflate() may update data_type if it can make a good guess about the
input data type (Z_ASCII or Z_BINARY)." Fortunately it says "may",
since it never has. The bug is that there is another data_type in an
internal structure that is set, but that is never copied back to the
user-supplied structure. Furthermore, that internal copy is never
initialized, hence the valgrind error. This bug will be fixed in the
next version of zlib. In all versions of zlib, data_type in the
user-supplied strucure is properly initialized to Z_UNKNOWN.

In any case, not setting data_type based on the input is permitted by
the interface description in zlib.h, and so no harm, no foul. The
guess about binary vs. ascii has no effect whatsover on the
compression.

By the way, these valgrind warnings are only showing up now in zlib
1.2.1 because previous versions of zlib (1.1.4 and earlier) defaulted
to calloc() for memory allocation, but zlib 1.2.1 now defaults to
malloc() in most cases for better speed. calloc() initializes
allocated memory to zero, but malloc() does not.

mark