Witek, in your commit 4a2fd2d964ef92a10219a3b5e4cce3a8b3be7782 to
elinks-0.12, you changed BIG_READ from 65536 to 655360.  Was this
change necessary for bug 1017?  The commit message says you
cherry picked it from 3131de4767475097eb60bb1641b39e6b647eb289,
but there is no similar BIG_READ change in that commit.

A similar change had been made in 0.13.GIT as part of bug 1008
(uploading big files), which has not been fixed in elinks-0.12.
However, it seems the BIG_READ change in bug 1008 was actually
an accident; bug 1008 was intended to affect only POST requests,
not decompression.

Commit b8b54a53259ea15014d7595e0f9e1475ae4aecf1 is where I merged
the bug 1008 changes to ELinks 0.13.GIT.  In those changes, you
originally gave BIG_READ an additional meaning: how large blocks
ELinks should read from a file that it's streaming to a server.
At the same time, you changed it to 655360, perhaps to make
uploading faster.  However, I then added read_http_post() and
made both HTTP and CGI use it, and that function does not use
BIG_READ any more.  Instead, its callers provide a buffer of size

Thus, it seems BIG_READ has been changed from 65536 to 655360 in
elinks-0.12 and master for no reason.  This consumes more memory
than before but I guess users can afford that nowadays.  However,
I worry that the large value can perhaps hide bugs in the
decompression code.  I mean, perhaps there is some bug that
occurs only when the compressed or decompressed data is over
BIG_READ bytes long.  If BIG_READ were smaller, then any such
bugs would be easier to find.

Attachment: pgpIPaSPT7hti.pgp
Description: PGP signature

elinks-dev mailing list

Reply via email to