Re: 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.