From jhawk at MIT.EDU  Sat Jun  2 16:47:25 2007
From: jhawk at MIT.EDU (John Hawkinson)
Date: Sat, 2 Jun 2007 18:47:25 -0400 (EDT)
Subject: [elinks-dev] Solaris build fixes
Message-ID: <200706022247.l52MlP4f003015@portnoy.mit.edu>

Hi, I'm not the list. Here are some fixes to build under Solaris 10
(no -rdynamic, no gzclearerr()). Against elinks-0.12-20070601.

Also included is a patch to add more help for -dump-color-mode.

--jhawk at mit.edu
  John Hawkinson

--- configure.in	2007/06/01 19:18:56	1.1
+++ configure.in	2007/06/02 22:21:07
@@ -256,10 +256,21 @@
 dnl
 dnl FIXME: This check doesn't work. Something to do with the compiler
 dnl happily ignoring it and stderr not being checked for error messages.
+dnl This works instead:
 AC_MSG_CHECKING([for -rdynamic])
 LDFLAGS_X="$LDFLAGS"
 LDFLAGS="$LDFLAGS -rdynamic"
-AC_TRY_LINK([], [], have_rdynamic=yes, have_rdynamic=no)
+cat > conftest.$ac_ext << _ACEOF
+int main() { return 0; }
+_ACEOF
+(eval $ac_compile) 2>conftest.er1
+(eval $ac_link) 2>conftest.err
+if test -s conftest.err
+then
+  have_rdynamic=no
+else
+  have_rdynamic=yes
+fi
 test "$have_rdynamic" = no && LDFLAGS="$LDFLAGS_X"
 AC_MSG_RESULT($have_rdynamic)
 
@@ -285,6 +296,7 @@
 AC_CHECK_FUNCS(getifaddrs getpwnam inet_pton inet_ntop)
 AC_CHECK_FUNCS(fflush fsync fseeko ftello sigaction)
 AC_CHECK_FUNCS(gettimeofday clock_gettime)
+AC_CHECK_FUNCS(gzclearerr)
 
 AC_HAVE_FUNCS(cygwin_conv_to_full_win32_path)
 
--- src/encoding/gzip.c	2007/05/31 22:40:05	1.1
+++ src/encoding/gzip.c	2007/06/02 22:22:20
@@ -33,7 +33,9 @@
 static int
 gzip_read(struct stream_encoded *stream, unsigned char *data, int len)
 {
+#ifdef HAVE_GZCLEARERR
 	gzclearerr((gzFile *) stream->data);
+#endif
 	return gzread((gzFile *) stream->data, data, len);
 }
 
--- src/config/cmdline.c	2007/06/02 21:44:28	1.1
+++ src/config/cmdline.c	2007/06/02 22:12:42
@@ -766,9 +766,19 @@
 		"dump-charset", 0, "document.dump.codepage",
 		N_("Codepage used when formatting dump output.")),
 
-	INIT_OPT_CMDALIAS("", N_("Color mode used with -dump"),
+	INIT_OPT_CMDALIAS("",
+                N_("Color mode used with -dump; "
+		   "takes a parameter from -1 to 4"),
 		"dump-color-mode", 0, "document.dump.color_mode",
-		N_("Color mode used with -dump.")),
+		N_("Color mode used with -dump.\n"
+		   "Takes a parameter:\n"
+		   "  -1: is standard dump mode\n"
+		   "   0: is mono mode\n"
+		   "   1: is 16 color mode\n"
+		   "   2: is 88 color mode\n"
+		   "   3: is 256 color mode\n"
+		   "   4: is true color mode"
+		   )),
 
 	INIT_OPT_CMDALIAS("", N_("Width of document formatted with -dump"),
 		"dump-width", 0, "document.dump.width",

From kon at iki.fi  Sun Jun  3 01:48:09 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sun, 03 Jun 2007 10:48:09 +0300
Subject: [elinks-dev] Solaris build fixes
In-Reply-To: <200706022247.l52MlP4f003015@portnoy.mit.edu>
References: <200706022247.l52MlP4f003015@portnoy.mit.edu>
Message-ID: <877iqlcwcm.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070603/a55fd59c/attachment.bin 

From fonseca at diku.dk  Sun Jun  3 03:16:19 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Sun, 3 Jun 2007 11:16:19 +0200
Subject: [elinks-dev] Solaris build fixes
In-Reply-To: <200706022247.l52MlP4f003015@portnoy.mit.edu>
References: <200706022247.l52MlP4f003015@portnoy.mit.edu>
Message-ID: <20070603091619.GB1419@diku.dk>

John Hawkinson <jhawk at MIT.EDU> wrote Sat, Jun 02, 2007:
> Hi, I'm not the list. Here are some fixes to build under Solaris 10
> (no -rdynamic, no gzclearerr()). Against elinks-0.12-20070601.
> 
> Also included is a patch to add more help for -dump-color-mode.
> 
> --jhawk at mit.edu
>   John Hawkinson
> 
> --- configure.in	2007/06/01 19:18:56	1.1
> +++ configure.in	2007/06/02 22:21:07
> @@ -256,10 +256,21 @@
>  dnl
>  dnl FIXME: This check doesn't work. Something to do with the compiler
>  dnl happily ignoring it and stderr not being checked for error messages.
> +dnl This works instead:
>  AC_MSG_CHECKING([for -rdynamic])
>  LDFLAGS_X="$LDFLAGS"
>  LDFLAGS="$LDFLAGS -rdynamic"
> -AC_TRY_LINK([], [], have_rdynamic=yes, have_rdynamic=no)
> +cat > conftest.$ac_ext << _ACEOF
> +int main() { return 0; }
> +_ACEOF
> +(eval $ac_compile) 2>conftest.er1
> +(eval $ac_link) 2>conftest.err
> +if test -s conftest.err
> +then
> +  have_rdynamic=no
> +else
> +  have_rdynamic=yes
> +fi
>  test "$have_rdynamic" = no && LDFLAGS="$LDFLAGS_X"
>  AC_MSG_RESULT($have_rdynamic)

Wow, this is really great. A lot of people has mentioned this over the
years and so finally being able to provide a fix is very helpful.

-- 
Jonas Fonseca

From jhawk at MIT.EDU  Sun Jun  3 09:54:35 2007
From: jhawk at MIT.EDU (John Hawkinson)
Date: Sun, 3 Jun 2007 11:54:35 -0400
Subject: [elinks-dev] Solaris build fixes
In-Reply-To: <877iqlcwcm.fsf@Astalo.kon.iki.fi>
References: <200706022247.l52MlP4f003015@portnoy.mit.edu>
	<877iqlcwcm.fsf@Astalo.kon.iki.fi>
Message-ID: <20070603155435.GY1749@multics.mit.edu>

Kalle Olavi Niemitalo <kon at iki.fi> wrote on Sun,  3 Jun 2007
at 10:48:09 +0300 in <877iqlcwcm.fsf at Astalo.kon.iki.fi>:

> I see.  The gzclearerr function was added in zlib 1.2.0.2,
> released on 2003-07-13.

Solaris 10 ships with zlib 1.1.4 (2002-03-11).

> Have you tested the resulting binary, especially with slow sites
> and Transfer-Encoding: chunked?

I have not...do you have a good test case?

> Can we assume that on Solaris 10 which does not have gzclearerr,
> stdio does not actually set the flag?

Hmm...Solaris 10 certainly does have clearerr(). The stdio
documentation is not very clear about when that flag is set.

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.

> Otherwise, can we work around the problem by disabling
> Accept-Encoding: gzip when gzclearerr is not available?

I suppose so. My focus was just trying to get elinks to build,
and I had the impression that the gzclearerr() was only necessary
in rare cases.

> So please also test 0.11.3 (or the upcoming 0.11.4) if possible.

I'd be happy to, given a test case.

--jhawk at mit.edu
  John Hawkinson

From kon at iki.fi  Mon Jun  4 11:43:58 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Mon, 04 Jun 2007 20:43:58 +0300
Subject: [elinks-dev] ELinks 0.11.3 and other changes to FSF's Free Software
	Directory
Message-ID: <874plnmx7l.fsf@Astalo.kon.iki.fi>

ELinks 0.11.3 was released on 2007-04-15.

Always use elinks.cz, not elinks.or.cz.

<http://ftp.pld-linux.org/pool/e/elinks/> has only ELinks 0.4pre18,
which is awfully old.  PLD has later versions available, e.g.
<ftp://ftp.pld-linux.org/dists/2.0/PLD/i386/PLD/RPMS/elinks-0.11.2-2.i386.rpm>
but unfortunately there doesn't seem to be a list of available
ELinks RPMs for different platforms.  I have collected some
pointers at <http://elinks.cz/download.html>.

According to <http://bugzilla.elinks.cz/show_bug.cgi?id=742>,
ELinks does not work with Lua 5.1.  So mention just 5.0, not 5.x.

The elinks-dev mailing list is gated to <news:gmane.comp.web.links>
as seen at <http://list.gmane.org/elinks-dev at linuxfromscratch.org>.
The name is misleading but GMANE is unable to rename newsgroups.

The elinks-bugs mailing list has been down for at least 7 months.


--- Elinks.txt~	2007-06-04 20:05:22.000000000 +0300
+++ Elinks.txt	2007-06-04 20:20:49.000000000 +0300
@@ -43,7 +43,7 @@
 
 %%touched: 2003-05-13
 
-%%updated: 2006-11-19
+%%updated: 2007-06-04
 
 %%keywords: elinks, browser, text mode, Internet, links
 
@@ -65,13 +65,13 @@
 Witold Filipczyk <witekfl at poczta.onet.pl>
 
 %%contributors: See the AUTHORS file in the distribution or
-http://elinks.or.cz/authors.html for a complete list
+http://elinks.cz/authors.html for a complete list
 
 %%sponsors: 
 
 %%changelog: http://elinks.cz/release.html
 
-%%source-tarball: http://elinks.cz/download/elinks-0.11.2.tar.bz2
+%%source-tarball: http://elinks.cz/download/elinks-0.11.3.tar.bz2
 
 %%source-info: http://elinks.cz/download.html
 
@@ -79,7 +79,7 @@
 
 %%debian: http://packages.debian.org/unstable/web/elinks.html
 
-%%rpm: http://ftp.pld-linux.org/pool/e/elinks/
+%%rpm: 
 
 %%repository: http://elinks.cz/elinks.git
 	      
@@ -87,7 +87,7 @@
 
 %%source-language: C
 
-%%supported-languages: lua 5.x, guile, Perl, Python, Ruby
+%%supported-languages: lua 5.0, guile, Perl, Python, Ruby
 
 %%use-requirements: 
 
@@ -106,7 +106,7 @@
 </pre>
 %%source-prerequisites:
 
-%%version: 0.11.2 stable released 2006-11-19
+%%version: 0.11.3 stable released 2007-04-15
 
 %%announce-list: <elinks-users at linuxfromscratch.org>
 
@@ -122,11 +122,11 @@
 %%dev-list: <elinks-dev at linuxfromscratch.org>
 	    http://linuxfromscratch.org/mailman/listinfo/elinks-dev/
 
-%%dev-news: 
+%%dev-news: gmane.comp.web.links
 
 %%dev-irc-channel: irc.freenode.net: #ELinks
 
-%%bug-list: <elinks-bugs at v.or.cz>
+%%bug-list: 
 
 %%bug-news: 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070604/33185db3/attachment.bin 

From kon at iki.fi  Mon Jun  4 15:29:46 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Tue, 05 Jun 2007 00:29:46 +0300
Subject: [elinks-dev] Solaris build fixes
In-Reply-To: <20070603155435.GY1749@multics.mit.edu>
References: <200706022247.l52MlP4f003015@portnoy.mit.edu>
	<877iqlcwcm.fsf@Astalo.kon.iki.fi>
	<20070603155435.GY1749@multics.mit.edu>
Message-ID: <87ejkr8l2t.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070605/96037bb7/attachment.bin 

From witekfl at poczta.onet.pl  Tue Jun  5 02:37:18 2007
From: witekfl at poczta.onet.pl (Witold Filipczyk)
Date: Tue, 5 Jun 2007 10:37:18 +0200
Subject: [elinks-dev] Solaris build fixes
In-Reply-To: <87ejkr8l2t.fsf@Astalo.kon.iki.fi>
References: <200706022247.l52MlP4f003015@portnoy.mit.edu>
	<877iqlcwcm.fsf@Astalo.kon.iki.fi>
	<20070603155435.GY1749@multics.mit.edu>
	<87ejkr8l2t.fsf@Astalo.kon.iki.fi>
Message-ID: <20070605083718.GA4438@pldmachine>

On Tue, Jun 05, 2007 at 12:29:46AM +0300, Kalle Olavi Niemitalo wrote:
> John Hawkinson <jhawk at MIT.EDU> writes:
> 
> > Kalle Olavi Niemitalo <kon at iki.fi> wrote on Sun,  3 Jun 2007
> > at 10:48:09 +0300 in <877iqlcwcm.fsf at Astalo.kon.iki.fi>:
> >
> >> 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.

From kon at iki.fi  Tue Jun  5 16:37:52 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Wed, 06 Jun 2007 01:37:52 +0300
Subject: [elinks-dev] Solaris build fixes
In-Reply-To: <20070605083718.GA4438@pldmachine>
References: <200706022247.l52MlP4f003015@portnoy.mit.edu>
	<877iqlcwcm.fsf@Astalo.kon.iki.fi>
	<20070603155435.GY1749@multics.mit.edu>
	<87ejkr8l2t.fsf@Astalo.kon.iki.fi> <20070605083718.GA4438@pldmachine>
Message-ID: <87646281tr.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070606/04c72380/attachment.bin 

From boeroboy at gmail.com  Wed Jun  6 09:51:00 2007
From: boeroboy at gmail.com (John Boero)
Date: Wed, 06 Jun 2007 10:51:00 -0500
Subject: [elinks-dev] Downloading 3.5 GB ISO
Message-ID: <4666D7E4.3030003@gmail.com>

Hi.  I distribute sabayon isos through my shared hosting account.  It's 
quickest for me to ssh into the host and download from my source 
directly (thanks to links).  This time I noticed quirky estimates on my 
larger files.  It looks like there's a signed int for tracking bytes 
received.  Could this be fixed by making it a long?

No big deal, just thought I'd make it known.

Thanks,
John

???????????????????????????? Download ????????????????????????????
?                                                                ?
?  http://mirror.cs.vt.edu/pub/SabayonLinux/SabayonLinux-x86...  ?
?                                                                ?
?  Received -776503292 B                                         ?
?  Average speed -208816 B/s, current speed 857 KiB/s            ?
?  Elapsed time 1:01:58                                          ?
?                                                                ?
?     [ Background ]  [ Background with notify ]  [ Abort ]      ?
?                                                                ?
?                   [ Abort and delete file ]                    ?
?                                                                ?
??????????????????????????????????????????????????????????????????

-776503292   = 0xFFFF FFFF D1B7 8004
-208816      = 0xFFFF FFFF FFFC D050

File size is roughly 3.5 GB

"Average speed" seems to decline with "Received"...  Maybe an overflow?


From kon at iki.fi  Thu Jun  7 16:08:04 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Fri, 08 Jun 2007 01:08:04 +0300
Subject: [elinks-dev] How to compile ELinks for Win32?
Message-ID: <87k5ufe7uj.fsf@Astalo.kon.iki.fi>

src/osdep/win32/ was last updated in ELinks 0.12.GIT on 2006-07-02.
From the commit messages, I get the impression that the Win32 port
is supposed to compile and link correctly and even work partially.
However, the build system of ELinks heavily depends on GNU Make and
POSIX utilities, and I believe these are not generally available on
Microsoft Windows.  Can ELinks be built on Windows in its current
condition, or must it be cross-compiled?  Which compiler and tools
should be used?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070608/986aaf65/attachment.bin 

From kon at iki.fi  Thu Jun  7 15:55:43 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Fri, 08 Jun 2007 00:55:43 +0300
Subject: [elinks-dev] ELinks 0.10.0 and later are GPLv2 only
Message-ID: <87ps47e8f4.fsf@Astalo.kon.iki.fi>

<http://directory.fsf.org/Elinks.html> claims "Licensed under The
GNU General Public License, Version 2 or later".  This seems to
have been true originally.  In elinks-0.9.3/src/dialogs/info.c:

> "This program is free software; you can redistribute it "
> "and/or modify it under the terms of the GNU General Public "
> "License as published by the Free Software Foundation; "
> "either version 2 of the License, or (at your option) any "
> "later version."),

However, in elinks-0.10.0/src/dialogs/info.c:

> "This program is free software; you can redistribute it "
> "and/or modify it under the terms of the GNU General Public "
> "License as published by the Free Software Foundation, "
> "specifically version 2 of the License."),

According to ChangeLog, this was changed on 2004-01-11,
thus after "%%license-verified-on: 2003-01-24".

There is also a further note in elinks-0.11.3/COPYING:

> Note that the only valid version of the GPL as far as ELinks is
> concerned is _this_ particular version of the license (ie v2, not v2.2
> or v3.x or whatever), unless explicitly stated otherwise. That is at
> least the policy for all pasky's contributions and the default - if you
> want different policy for your patches, the best way to state it is by
> a patch for your AUTHORS entry.
> 
> If pasky likes GPLv3, he might relicence his contributions for GPLv3
> as well. The default policy should probably be that you trust pasky,
> Jonas, or the current maintainer of the day to do the right thing (much
> like it is in the Linux kernel). But this needs to be yet worked out
> and agreed upon.

Please update the licensing information in the Free Software Directory.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070608/c8820d1a/attachment.bin 

From fonseca at diku.dk  Thu Jun  7 21:54:58 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Fri, 8 Jun 2007 05:54:58 +0200
Subject: [elinks-dev] How to compile ELinks for Win32?
In-Reply-To: <87k5ufe7uj.fsf@Astalo.kon.iki.fi>
References: <87k5ufe7uj.fsf@Astalo.kon.iki.fi>
Message-ID: <20070608035458.GA32446@diku.dk>

Kalle Olavi Niemitalo <kon at iki.fi> wrote Fri, Jun 08, 2007:
> src/osdep/win32/ was last updated in ELinks 0.12.GIT on 2006-07-02.
> From the commit messages, I get the impression that the Win32 port
> is supposed to compile and link correctly and even work partially.
> However, the build system of ELinks heavily depends on GNU Make and
> POSIX utilities, and I believe these are not generally available on
> Microsoft Windows.  Can ELinks be built on Windows in its current
> condition, or must it be cross-compiled?  Which compiler and tools
> should be used?

The last time I worked and tested this I used MSYS / MingW, which comes
with gmake and shell utilities to run the configure script. I haven't
tried since.

-- 
Jonas Fonseca

From fonseca at diku.dk  Thu Jun  7 22:35:57 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Fri, 8 Jun 2007 06:35:57 +0200
Subject: [elinks-dev] Downloading 3.5 GB ISO
In-Reply-To: <4666D7E4.3030003@gmail.com>
References: <4666D7E4.3030003@gmail.com>
Message-ID: <20070608043557.GB32446@diku.dk>

John Boero <boeroboy at gmail.com> wrote Wed, Jun 06, 2007:
> Hi.  I distribute sabayon isos through my shared hosting account.  It's 
> quickest for me to ssh into the host and download from my source 
> directly (thanks to links).  This time I noticed quirky estimates on my 
> larger files.  It looks like there's a signed int for tracking bytes 
> received.

Could you tell us about what version of ELinks you are using?

> Could this be fixed by making it a long?

The off_t type should be used for this kind of thing; it seems Witold
already made such preparations.

> No big deal, just thought I'd make it known.

Thank you for reporting this.

... and now some comments to the patch

> From 6e43bca585238183c6a3f04695b48b755b1b52b6 Mon Sep 17 00:00:00 2001
> From: Witold Filipczyk <witekfl at poczta.onet.pl>
> Date: Thu, 7 Jun 2007 16:16:53 +0200
> Subject: [PATCH] http: used off_t instead of int.
> 
> The progress of files bigger than 2GB is shown properly.
> ---
>  src/protocol/http/http.c |   10 +++++-----
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/src/protocol/http/http.c b/src/protocol/http/http.c
> index 62f7c3f..71086c3 100644
> --- a/src/protocol/http/http.c
> +++ b/src/protocol/http/http.c
> @@ -74,13 +74,13 @@ struct http_connection_info {
>  
>  #define LEN_CHUNKED -2 /* == we get data in unknown number of chunks */
>  #define LEN_FINISHED 0
> -	int length;
> +	off_t length;
>  
>          /* Either bytes coming in this chunk yet or "parser state". */
>  #define CHUNK_DATA_END	-3
>  #define CHUNK_ZERO_SIZE	-2
>  #define CHUNK_SIZE	-1
> -	int chunk_remaining;
> +	off_t chunk_remaining;

This change should have some consequences for decompress_data calling
also I think. At least we need to check for overflows before trunkating
and assigning the value of this to the len parameter passed to
decompress_data. The code in question:

	...
        int len;
        int zero = (http->chunk_remaining == CHUNK_ZERO_SIZE);

        if (zero) http->chunk_remaining = 0;
        len = http->chunk_remaining;

        /* Maybe everything necessary didn't come yet.. */
        int_upper_bound(&len, rb->length);
        conn->received += len;
        
        data = decompress_data(conn, rb->data, len, &data_len);
	...

I am not sure if this should also be updated to use strtoll:

        unsigned char *de;
        int n = 0;

        if (l != -1) {
                errno = 0;
                n = strtol(rb->data, (char **) &de, 16);
                if (errno || !*de) {
                        return -1;
                }
        }

        if (l == -1 || de == rb->data) {
                return -1;
        }

        /* Remove everything to the EOLN. */
        kill_buffer_data(rb, l);
        http->chunk_remaining = n;
 
... or whether chunk_remaining should even be off_t, but it clearly
results in fewer changes needed to decompress_data.

The problem with potential overflows should also be investigated with
respect the http_connection_info->length member. The only code where
this could be a problem seems to be this. Since the check already
ensures that http->length is smaller than an already known-good value,
it should be OK, I think:

	read_normal_http_data(struct connection *conn, struct read_buffer *rb)
	{
	        struct http_connection_info *http = conn->info;
	        unsigned char *data;
	        int data_len;
	        int len = rb->length;

        	if (http->length >= 0 && http->length < len) {
        	        /* We won't read more than we have to go. */
        	        len = http->length;
        	}

>          int code;
>  };
> @@ -1007,7 +1007,7 @@ decompress_data(struct connection *conn, unsigned char *data, int len,
>           * early otherwise)). */
>          enum { NORMAL, FINISHING } state = NORMAL;
>          int did_read = 0;
> -	int *length_of_block;
> +	off_t *length_of_block;
>          unsigned char *output = NULL;
>  
>          length_of_block = (http->length == LEN_CHUNKED ? &http->chunk_remaining
> @@ -1761,10 +1761,10 @@ again:
>          d = parse_header(conn->cached->head, "Content-Length", NULL);
>          if (d) {
>                  unsigned char *ep;
> -		int l;
> +		off_t l;
>  
>                  errno = 0;
> -		l = strtol(d, (char **) &ep, 10);
> +		l = strtoll(d, (char **) &ep, 10);
>  
>                  if (!errno && !*ep && l >= 0) {
>                          if (!http->close || POST_HTTP_1_0(version))
> -- 
> 1.5.2.1.851.g432c-dirty

-- 
Jonas Fonseca

From kon at iki.fi  Sat Jun  9 02:27:28 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sat, 09 Jun 2007 11:27:28 +0300
Subject: [elinks-dev] Crash bug and proposed patch
In-Reply-To: <8764fro6po.fsf@Astalo.kon.iki.fi>
References: <20060913073924.GB17061@joeysmith.com>
	<8764fro6po.fsf@Astalo.kon.iki.fi>
Message-ID: <87ps451qj3.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070609/ff82e57a/attachment.bin 

From kon at iki.fi  Sat Jun  9 05:20:00 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sat, 09 Jun 2007 14:20:00 +0300
Subject: [elinks-dev] problems in elinkskeys.5
In-Reply-To: <87ejq8q6je.fsf@Astalo.kon.iki.fi> (Kalle Olavi Niemitalo's
	message of "Sat, 06 Jan 2007 21:49:57 +0200")
References: <200701041934.l04JYWlY002641@snark.thyrsus.com>
	<87ejq8q6je.fsf@Astalo.kon.iki.fi>
Message-ID: <87lket1ijj.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070609/906b97a1/attachment.bin 

From kon at iki.fi  Sat Jun  9 08:38:12 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sat, 09 Jun 2007 17:38:12 +0300
Subject: [elinks-dev] Edit mode not exiting cleanly on "Back"
In-Reply-To: <464340B0.3010404@seiner.com> (Yan Seiner's message of "Thu, 10
	May 2007 08:56:32 -0700")
References: <463FA3CB.2030304@seiner.com> <87zm4fn8ju.fsf@Astalo.kon.iki.fi>
	<46409366.7030804@seiner.com> <87vef3m2sk.fsf@Astalo.kon.iki.fi>
	<464340B0.3010404@seiner.com>
Message-ID: <87d50519d7.fsf@Astalo.kon.iki.fi>

Yan Seiner <yan at seiner.com> writes:

> More of a hack rather than a fix as it leaves the same problem for all 
> the other actions, but it fixes it for this one special case.

I have entered this bug at <http://bugzilla.elinks.cz/show_bug.cgi?id=953>.
Please feel free to attach your patch there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070609/3cc742d0/attachment.bin 

From kon at iki.fi  Sat Jun  9 09:14:57 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sat, 09 Jun 2007 18:14:57 +0300
Subject: [elinks-dev] Memory allocation
In-Reply-To: <20070531133730.GC27044@diku.dk> (Jonas Fonseca's message of
	"Thu, 31 May 2007 15:37:30 +0200")
References: <20070530153242.GA4594@pldmachine>
	<87ps4ikmsl.fsf@Astalo.kon.iki.fi> <20070531133730.GC27044@diku.dk>
Message-ID: <877iqd17ny.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070609/0a07747b/attachment.bin 

From kon at iki.fi  Sun Jun 10 07:12:29 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sun, 10 Jun 2007 16:12:29 +0300
Subject: [elinks-dev] Is onsubmit being called for reset buttons too?
In-Reply-To: <87d5hvll4y.fsf@Astalo.kon.iki.fi>
References: <87d5hvll4y.fsf@Astalo.kon.iki.fi>
Message-ID: <87zm38ymv6.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070610/73875985/attachment.bin 

From kon at iki.fi  Mon Jun 11 01:29:10 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Mon, 11 Jun 2007 10:29:10 +0300
Subject: [elinks-dev] Solaris build fixes
In-Reply-To: <87ejkr8l2t.fsf@Astalo.kon.iki.fi>
References: <200706022247.l52MlP4f003015@portnoy.mit.edu>
	<877iqlcwcm.fsf@Astalo.kon.iki.fi>
	<20070603155435.GY1749@multics.mit.edu>
	<87ejkr8l2t.fsf@Astalo.kon.iki.fi>
Message-ID: <874plfkkzd.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070611/eea3fd8c/attachment.bin 

From kon at iki.fi  Mon Jun 11 01:42:38 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Mon, 11 Jun 2007 10:42:38 +0300
Subject: [elinks-dev] Solaris build fixes
In-Reply-To: <20070603091619.GB1419@diku.dk>
References: <200706022247.l52MlP4f003015@portnoy.mit.edu>
	<20070603091619.GB1419@diku.dk>
Message-ID: <87zm37j5sh.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070611/ff5bd545/attachment.bin 

From kon at iki.fi  Mon Jun 11 11:22:02 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Mon, 11 Jun 2007 20:22:02 +0300
Subject: [elinks-dev] pwmd patch
In-Reply-To: <200701281810.l0SIA2r3015117@rs19.luxsci.com>
References: <200701281810.l0SIA2r3015117@rs19.luxsci.com>
Message-ID: <87ejki76f9.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070611/cb2e8833/attachment.bin 

From witekfl at poczta.onet.pl  Fri Jun 15 06:49:20 2007
From: witekfl at poczta.onet.pl (Witold Filipczyk)
Date: Fri, 15 Jun 2007 14:49:20 +0200
Subject: [elinks-dev] CGI scripts using GET don't work
Message-ID: <20070615124920.GA10529@pldmachine>

Hi!
CGI scripts using the GET method don't work in 0.11.3
and 0.12.GIT. QUERY_STRING is empty. It's a big bug.
Here is the patch for 0.11.3:
diff --git a/src/protocol/uri.c b/src/protocol/uri.c
index df22646..e9c3b39 100644
--- a/src/protocol/uri.c
+++ b/src/protocol/uri.c
@@ -149,7 +149,7 @@ static int
 check_uri_file(const unsigned char *name)
 {
 	/* Check POST_CHAR etc ... */
-	static const unsigned char chars[] = POST_CHAR_S "#?";
+	static const unsigned char chars[] = POST_CHAR_S "#";
 
 	return strcspn(name, chars);
 }

-- 
Witek

From kon at iki.fi  Sun Jun 17 05:30:20 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sun, 17 Jun 2007 14:30:20 +0300
Subject: [elinks-dev] CGI scripts using GET don't work
In-Reply-To: <20070615124920.GA10529@pldmachine>
References: <20070615124920.GA10529@pldmachine>
Message-ID: <877iq2ddir.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070617/e7451e66/attachment.bin 

From witekfl at poczta.onet.pl  Tue Jun 19 04:13:12 2007
From: witekfl at poczta.onet.pl (Witold Filipczyk)
Date: Tue, 19 Jun 2007 12:13:12 +0200
Subject: [elinks-dev] Date format for directory listings
Message-ID: <20070619101312.GA4560@pldmachine>

Hi!
Date formats differ among various locales.
Those used by ELinks in directory listings may not be appropriate for everyone.
IMHO there are 3 choices:
- leave them as they are
- let user to define them
- use gettext

Which choice do you prefer?
I prefer gettext myself, but I want to know your opinions.

-- 
Witek


From kon at iki.fi  Tue Jun 19 15:23:44 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Wed, 20 Jun 2007 00:23:44 +0300
Subject: [elinks-dev] Date format for directory listings
In-Reply-To: <20070619101312.GA4560@pldmachine>
References: <20070619101312.GA4560@pldmachine>
Message-ID: <87sl8n4p0f.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070620/44bcf275/attachment.bin 

From witekfl at poczta.onet.pl  Tue Jun 19 16:21:53 2007
From: witekfl at poczta.onet.pl (Witold Filipczyk)
Date: Wed, 20 Jun 2007 00:21:53 +0200
Subject: [elinks-dev] Date format for directory listings
In-Reply-To: <87sl8n4p0f.fsf@Astalo.kon.iki.fi>
References: <20070619101312.GA4560@pldmachine>
	<87sl8n4p0f.fsf@Astalo.kon.iki.fi>
Message-ID: <20070619222153.GA22676@pldmachine>

On Wed, Jun 20, 2007 at 12:23:44AM +0300, Kalle Olavi Niemitalo wrote:
> Witold Filipczyk <witekfl at poczta.onet.pl> writes:
> 
> > Date formats differ among various locales.
> > Those used by ELinks in directory listings may not be appropriate for everyone.
> 
> Are they appropriate for you?

No. I would like "%e %4b  %Y" instead of "%b %e  %Y".

> Do users complain?
> 
> > IMHO there are 3 choices:
> > - leave them as they are
> > - let user to define them
> > - use gettext
> 
> Are you going to get the "Jan" "Mon" "AM" etc. strings from libc
> (via strftime or nl_langinfo) or put them in elinks/po too?
> Reading locale data from libc based on the ELinks language
> setting is not entirely trivial:
> 
> - As was briefly discussed in #ELinks on 2007-04-14, POSIX
>   does not specify names of locales, except "C" and "POSIX".
>   _nl_find_domain() in elinks/src/intl/gettext/finddomain.c
>   already parses names of locales and has to make some
>   assumptions on their syntax, but constructing such names
>   would require even further assumptions.
> 
> - There is also the possibility that the locale is in principle
>   supported by libc but has not been installed.  In Debian, this
>   is controlled via /etc/locale.gen.  In such cases though, I
>   think the users should just ask the sysadmin to install it.

Do I write too enigmatic?
I want to translate only format strings not results of strftime.
> 
> If you put the strings in elinks/po and reimplement strftime,
> I think it will be bloat... especially if we ever get a ja.po
> and have to add emperor data to support "%EY".  Probably that
> won't happen before Shift-JIS charset support though.

I doubt that someone reimplement (change behaviour) strftime.
When the format string changes in the code, old translations
will be invalid and ELinks choose the text from the code, not
from .mo files. I see no problem here.
Three more items (the format for fresh files, the format for older
ones and the format for spaces) to translate is a bloat?

-- 
Witek

From kon at iki.fi  Wed Jun 20 10:07:09 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Wed, 20 Jun 2007 19:07:09 +0300
Subject: [elinks-dev] Date format for directory listings
In-Reply-To: <20070619222153.GA22676@pldmachine>
References: <20070619101312.GA4560@pldmachine>
	<87sl8n4p0f.fsf@Astalo.kon.iki.fi> <20070619222153.GA22676@pldmachine>
Message-ID: <87odja4nki.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070620/e1b9a38b/attachment.bin 

From kon at iki.fi  Sun Jun 24 03:41:38 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sun, 24 Jun 2007 12:41:38 +0300
Subject: [elinks-dev] Submit ELinks to the Free Translation Project?
Message-ID: <87zm2p4rl9.fsf@Astalo.kon.iki.fi>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20070624/04f73840/attachment.bin