> The workaround is not friendly with *.gz files that are > 2G.
> (and zlib 1.1.3 has a bug inside - hardcodes off_t to unsigned long
> in internal structs) How should we address this issue?
(Note to pedants: in the following discussion, "friendly, on platforms
with 32-bit 'long's and 64-bit 'off_t's, towards files >2G" shall be
abbreviated as "friendly towards files >2G". :-))
If the ".gz" file is >2G, the file presumably has more than 2GB of data;
Ethereal can't handle that on systems with 32-bit "long"s:
% egrep file_off packet.h
long file_off; /* File offset */
and Wiretap may have similar problems.
I.e., right now, *Ethereal* isn't friendly towards files >2G, period, so
the workaround doesn't make anything worse.
Furthermore, if libz support *isn't* included, "file_seek()" does
"fseek()"s, and the file offset argument to "fseek()" is a "long", not
an "off_t", so even fixing "file_off" and any Wiretap issues *still*
doesn't make Ethereal completely friendly towards files >2G.
Of the 4.4-Lite-based OSes, {Free,Net,Open}BSD all include libz, so,
*if* libz were friendly towards files >2G (which, as you note, it isn't
- and note that, when reading *uncompressed* files, it uses "fseek()",
so there's more to making it friendly towards files >2G than just fixing
offsets), "fseek()" wouldn't be much of an issue because Wiretap and
thus Ethereal wouldn't use "fseek()" unless you explicitly configured
with "--disable-zlib".
However, I don't know whether the same is true of BSD/OS, so "fseek()"
is an issue there unless you install libz (and then it becomes, without
changes to libz, an issue with *libz* rather than an issue with
Ethereal/Wiretap).