This isn't the right type anyway to assure that it contains a
pointer. That type would be intptr_t or uintptr_t. However the C99
standard says that those types are optional, so their use would not
be portable. This commit simply uses size_t or whatever configure
decided to use for size_t. That would be the same length as
ptrdiff_t, and so will work just as well. The code checks to see if
the length of the type used is the same as the length of a void
pointer, so there is already protection against the use of the
wrong type. The use of size_t (or ptrdiff_t) will almost always
work, as all modern architectures have an array size that is the
same as the pointer size. Only old segmented architectures would
have to fall back to the slower CRC-32 calculation, where the
amount of memory that can be accessed is larger than the maximum
array size.
See the comment for more details. This is in response to an issue
raised as a result of a security audit of the zlib code by Trail
of Bits and TrustInSoft, in support of the Mozilla Foundation.
There was a small optimization for PowerPCs to pre-increment a
pointer when accessing a word, instead of post-incrementing. This
required prefacing the loop with a decrement of the pointer,
possibly pointing before the object passed. This is not compliant
with the C standard, for which decrementing a pointer before its
allocated memory is undefined. When tested on a modern PowerPC
with a modern compiler, the optimization no longer has any effect.
Due to all that, and per the recommendation of a security audit of
the zlib code by Trail of Bits and TrustInSoft, in support of the
Mozilla Foundation, this "optimization" was removed, in order to
avoid the possibility of undefined behavior.
crc_table is made using a four-byte integer (when that can be
determined). However get_crc_table() returned a pointer to an
unsigned long, which could be eight bytes. This fixes that by
creating a new z_crc_t type for the crc_table.
This type is also used for the BYFOUR crc calculations that depend
on a four-byte type. The four-byte type can now be determined by
./configure, which also solves a problem where ./configure --solo
would never use BYFOUR. No the Z_U4 #define indicates that four-
byte integer was found either by ./configure or by zconf.h.
crc32.c was #including limits.h in order to find a four-byte integer
type. It was doing this even if Z_SOLO were defined, violating the
intent of Z_SOLO, which is to include no library headers and require
no library functions. Now crc32.c obeys the intent of Z_SOLO, but
with the downside that crc32() will be slower than when not compiled
with Z_SOLO. This can be remedied manually by typedefing u4 to a
known four-byte unsigned integer type, and #defining BYFOUR in
crc32.c.
