SpiderMonkey was updated to mozjs24. If you want to build elinks
with ecmascript support, you must compile using g++ with -fpermissive .
There is a lot of warnings.
There are some memleaks in ecmascript code, especially related to JSAutoCompartment.
I don't know yet, where and how to free it.
Debian does not support mozjs24, so I'm going to gradually update SpiderMonkey version.
Weak points:
- alignof
- js problems
Todo:
- make js work with C++ and mozjs-17
- then mozjs-24
- then mozjs-52
- then mozjs-60
- decrease number of warnings
Replace almost all uses of enum connection_state with struct
connection_status. This removes the assumption that errno values used
by the system are between 0 and 100000. The GNU Hurd uses values like
ENOENT = 0x40000002 and EMIG_SERVER_DIED = -308.
This commit is derived from my attachments 450 and 467 to bug 1013.
Avoid this warning:
[CC] src/encoding/deflate.o
cc1: warnings being treated as errors
/home/Kalle/src/elinks-0.12/src/encoding/deflate.c: In function ‘deflate_read’:
/home/Kalle/src/elinks-0.12/src/encoding/deflate.c:96: warning: ‘l’ may be used uninitialized in this function
I am reverting all /dev/fd recognition because of bug 917.
This reverts commit c283f8cfd9,
except src/protocol/file/file.c still needs #include "osdep/osdep.h"
for STRING_DIR_SEP.
Without this patch, ELinks showed garbage at
<http://www.dwheeler.com/oss_fs_why.html> when bzip2 decompression was
enabled. safe_read() in bzip2_read() did not see all of the body
bytes that ELinks had received from the server. After bzip2_read()
received EAGAIN from safe_read() and returned 0, something skipped
1460 bytes.
decompress_data() apparently assumed that read_encoded() returning 0
meant the end of the file, and returned even though len still was
nonzero, i.e. it had not yet written to the pipe all the data that
the caller (read_chunked_http_data() or read_normal_http_data()) had
provided. The caller did not know this, and discarded the data.
(cherry picked from commit 7e5e05ca60)
Without this patch, ELinks showed garbage at
<http://www.dwheeler.com/oss_fs_why.html> when bzip2 decompression was
enabled. safe_read() in bzip2_read() did not see all of the body
bytes that ELinks had received from the server. After bzip2_read()
received EAGAIN from safe_read() and returned 0, something skipped
1460 bytes.
decompress_data() apparently assumed that read_encoded() returning 0
meant the end of the file, and returned even though len still was
nonzero, i.e. it had not yet written to the pipe all the data that
the caller (read_chunked_http_data() or read_normal_http_data()) had
provided. The caller did not know this, and discarded the data.
deflate.c used to call inflateInit2(stream, MAX_WBITS + 32).
This makes zlib first check for a gzip header, and if it doesn't
find one, assume a zlib header. However, if the server said
"Content-Encoding: deflate", then neither header is there, and
zlib does not detect this automatically. So ELinks has to
distinguish between the gzip and deflate encodings, and tell
zlib which one was meant.
This bug resulted in blank pages at blogs.msdn.com accessed
through proxy.suomi.net.
Previously, bzip2_decode_buffer and deflate_decode_buffer left
*new_len unchanged if the compressed input data ended unexpectedly.
This behaviour was also inherited by decode_encoded_buffer,
whose only caller render_encoded_document preinitializes the variable
and so did not crash.
With this change, the functions now store in *new_len the number of
bytes that were successfully decoded, even if more bytes were expected.
An error should perhaps be reported to the user, but I don't think the
previous version did that either, as it returned a non-NULL pointer.
This function was unused and only the dummy backend implemented it
correctly. Fixing bug 534 will probably require adding this function
back again, but I think it will be easier to do it from scratch than
fix the bogus implementations we had here.
This is necessary when using a POSIX-compliant stdio implementation, which
will set the FILE error flag when input from the pipe is exhausted, causing
all subsequent reads to fail.
