Witold Filipczyk <[EMAIL PROTECTED]> writes: > On Tue, Jun 05, 2007 at 12:29:46AM +0300, Kalle Olavi Niemitalo wrote: >> clearerr() needs a FILE *, not a file descriptor. And >> gzip_open() calls fdopen() itself, so ELinks never sees >> the FILE *.
I should have written that gz_open() in zlib calls fdopen() itself.
gzip_open() in ELinks calls gzdopen(), which calls gz_open().
>> (b) Revert all the decompression changes from elinks-0.12,
>> returning to what was in ELinks 0.11.3.
>
> The old code doesn't work well everywhere, so gzclearerr was added
> and then the decompression code was simplified (?).
Where does it not work? Is there a test case?
> (e) Write ELinks's gzclearerr using internals of the zlib of Solaris 10.
> Check for gzclearerr in ./configure. If it fails use own function
> and warn the user.
I fear that would cause crashes later when Sun upgrades zlib and
changes struct gz_stream. Probably the upgrade would be to a
version later than zlib 1.2.0.2 though, so recompiling ELinks
would then fix the crashes. (I did implement a similar hack in
do_fsp(), but that reads only an integer and not a pointer, so it
won't crash even if the result is wrong.) Then there may also be
other operating systems with different old versions of zlib.
Does zlib 1.1.4 as shipped in Solaris 10 include any Sun patches
that change the definition of struct gz_stream in gzio.c?
How hard is it for Solaris 10 users to install a newer version of
zlib, e.g. in /usr/local?
(f) Include recent zlib sources with ELinks and link it
statically if the installed version is not suitable.
http://www.fsf.org/licensing/licenses/index_html says
the zlib license is compatible with GNU GPL (as it should
if ELinks is already linking with it). But the required
changes in the build system might already be more complex
than (d) rewriting the decompression code in ELinks.
> I wonder what happens when part of the gzip header is in the first chunk
> and the rest in the next one.
I did not see any bugs in 0.12.GIT when I ran the test CGI with a
block size of one byte (and a shorter sleep).
pgpcsdLFUv6Bj.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
