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 POST_BUFFER_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.
pgpIPaSPT7hti.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev