Re: [elinks-dev] Solaris build fixes
On Tue, Jun 05, 2007 at 12:29:46AM +0300, Kalle Olavi Niemitalo wrote:
John Hawkinson [EMAIL PROTECTED] writes:
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote on Sun, 3 Jun 2007
at 10:48:09 +0300 in [EMAIL PROTECTED]:
Have you tested the resulting binary, especially with slow sites
and Transfer-Encoding: chunked?
I have not...do you have a good test case?
-
#! /usr/bin/perl
use strict;
use IPC::Open2;
print EOH;
Content-Type: text/plain
Content-Encoding: gzip
EOH
local $| = 1;
open PLAIN, , /home/Kalle/src/elinks-0.12/COPYING or die;
my $pid = open2(\*GZIP, PLAIN, gzip -1);
local $/ = \4567;
while (GZIP) { print; sleep 1 }
-
If I comment out the gzclearerr call in gzip_read, the output is
truncated after that is to say, a work. With different input
files, ELinks can display garbage too. No such problems in
ELinks 0.11.3.
Would it be sufficient to call clearerr() on the fd that
gzip_open() was called with? I guess it would be hairy to save
the fd.
clearerr() needs a FILE *, not a file descriptor. And
gzip_open() calls fdopen() itself, so ELinks never sees
the FILE *. There is no function in zlib for retrieving
the pointer, either.
So then, there seem to be four options:
(a) Just skip gzclearerr and ignore the resulting corruption.
This would be a regression from 0.11.3.
(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 (?).
(c) Partially or completely disable gzip decompression on
platforms that don't have gzclearerr. Document that ELinks
needs at least zlib 1.2.0.2 for full support.
(d) Rewrite the decompression code or at least the gzip part of
it. I don't have an estimate on how long this would take.
It would be too easy to slip in new bugs in this process.
(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 think it would be best to do (c) in 0.12.GIT and (d) in 0.13.GIT.
I wonder what happens when part of the gzip header is in the first chunk
and the rest in the next one.
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Solaris build fixes
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
