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
This prevents links with null selectors being interpreted as pointing to
a (likely non-existent) file gopher://server/1
An example of a page with such links: gopher://gopher.floodgap.com/1/new
DELETED:
* dumb {b}, smart {bb, bb_fr_en, bb_en_fr}: Redirects to Microsoft
Translator, which I can't get to work without JavaScript. Deleted.
* dumb {pyhelp}, smart {py, pydev}: Deleted as recommended by the
author of the CGI script.
* dumb {pyvault, lyrics}, smart {pyvault}: Can't find a new URL for the
service. Deleted.
* smart {gd}: Google Directory has been shut down. Deleted.
* smart {sd, sdc, sdu, sdp, sdj, whatis}: These don't seem to work
without JavaScript. Deleted.
* smart {id, draft}: The search still exists but I can't get it to
take the words from the URL. Deleted.
UPDATED:
* dumb {cia}: Had changed its URL, and the service is down, but they
intend to restore it. Updated and kept.
* dumb {lua}: ELinks no longer supports Lua 4.0. Changed to 5.1 as
installed by Debian.
* smart {cliki, foldoc, gwho, gwhat, gwhere, gwhen, a, imdb, wn, fsd,
rfcs, cr}: Updated URLs.
Doxygen warned that <uri> is an unsupported xml/html tag.
It was not intended as a tag though; rather as a placeholder
akin to <var>uri</var>. Escape with a backslash.
In almost all calls to parse_header, the second argument is a string
literal: parse_header(head, "Charset", NULL) for example.
Of course, parse_header does not write to that string. Accordingly,
make the parameter point to const, so calls that use a variable rather
than a string literal can make that variable point to const too.
Leaving the other parameters non-const for now.
http_negotiate_parse_data passed &token->length as the int *outlen
parameter of base64_decode_bin, which stores an int at that location.
However, gss_buffer_desc::length is size_t in all implementations that
I checked: MIT Kerberos Version 5 Release 1.10, libgssglue 0.4, and
GNU GSS 1.0.2. This mismatch could cause the build to fail:
.../src/protocol/http/http_negotiate.c: In function ‘http_negotiate_parse_data’:
.../src/protocol/http/http_negotiate.c:173:2: error: passing argument 3 of ‘base64_decode_bin’ from incompatible pointer type [-Werror]
In file included from .../src/protocol/http/http_negotiate.c:30:0:
.../src/util/base64.h:8:16: note: expected ‘int *’ but argument is of type ‘size_t *’
On 64-bit big-endian hosts, it might also cause the GSSAPI
implementation to read too much data from memory and disclose it to
some network server, or crash ELinks.
(cherry picked from elinks-0.12 commit d33c807dd9)
INIT_OPTION used to initialize union option_value at compile time by
casting the default value to LIST_OF(struct option) *, which is the
type of the first member. On sparc64 and other big-endian systems
where sizeof(int) < sizeof(struct list_head *), this tended to leave
option->value.number as zero, thus messing up OPT_INT and OPT_BOOL
at least. OPT_LONG however tended to work right.
This would be easy to fix with C99 designated initializers,
but doc/hacking.txt says ELinks must be kept C89 compatible.
Another solution would be to make register_options() read the
value from option->value.tree (the first member), cast it back
to the right type, and write it to the appropriate member;
but that would still require somewhat dubious conversions
between integers, data pointers, and function pointers.
So here's a rather more invasive solution. Add struct option_init,
which is somewhat similar to struct option but has non-overlapping
members for different types of values, to ensure nothing is lost
in compile-time conversions. Move unsigned char *path from struct
option_info to struct option_init, and replace struct option_info
with a union that contains struct option_init and struct option.
Now, this union can be initialized with no portability problems,
and register_options() then moves the values from struct option_init
to their final places in struct option.
In my x86 ELinks build with plenty of options configured in, this
change bloated the text section by 340 bytes but compressed the data
section by 2784 bytes, presumably because union option_info is a
pointer smaller than struct option_info was.
(cherry picked from elinks-0.12 commit e5f6592ee2)
Conflicts:
src/protocol/fsp/fsp.c: All options had been removed in 0.13.GIT.
src/protocol/smb/smb2.c: Ditto.
... and mention that URI rewriting rules may leak ELinks' identity
in the documentation of protocol.http.user_agent.
Originally requested at <https://bugzilla.redhat.com/856348>.
read_http_post_inline decodes two hexadecimal digits into one byte at
a time, and it asserts that each hexadecimal digit is valid; however,
both assertions print the first digit when they fail. Fix the assertion
on the second digit to print the second digit.
than 2GiB in the download dialog. Also let regetting big files.
Previously the Content-Length variable in http.c was int, what is
not enough. Now it is long long.
There are two identical tp_show_header() functions: one in
src/session/download.c and one in src/protocol/bittorrent/dialogs.c.
Neither is declared in any header, but the latter was not static.
Documentation strings of most options used to contain a "\n" at the
end of each source line. When the option manager displayed these
strings, it treated each "\n" as a hard newline. On 80x24 terminals
however, the option description window has only 60 columes available
for the text (with the default setup.h), and the hard newlines were
further apart, so the option manager wrapped the text a second time,
resulting in rather ugly output where long lones are interleaved with
short ones. This could also cause the text to take up too much
vertical space and not fit in the window.
Replace most of those hard newlines with spaces so that the option
manager (or perhaps BFU) will take care of the wrapping. At the same
time, rewrap the strings in source code so that the source lines are
at most 79 columns wide.
In some options though, there is a list of possible values and their
meanings. In those lists, if the description of one value does not
fit in one line, then continuation lines should be indented. The
option manager and BFU are not currently able to do that. So, keep
the hard newlines in those lists, but rewrap them to 60 columns so
that they are less likely to require further wrapping at runtime.
This makes the option manager display it much better on an 80x24
terminal.
Alternatively, the "\n" newline characters within paragraphs could
have been removed entirely. ELinks would then have line-wrapped the
text to the appropriate width in the info window of the option
manager, but unfortunately not in --config-help.
AFAIK, all bugs in it have been fixed. Some bugs may still be lurking
but they are more likely to get caught if compression is enabled.
I also replaced COMP_NOTE with static text because xgettext does not
support macros in the argument of N_.
(cherry picked from commit 3a9b5d091d)
This simplifies the callers a little and may help implement
simultaneous support for different charsets on different terminals
of the same type (bug 1064).
Except if they have external handlers.
When ELinks receives an event from a terminal, move that terminal to
the beginning of the global "terminals" list, so that the terminals
are always sorted according to the time of the most recent use. Note,
this affects the numbering of bookmark folders in session snapshots.
Add get_default_terminal(), which returns the most recently used
terminal that is still open. Use that in various places that
previously used terminals.prev or terminals.next. Four functions
fetch the size of the terminal for User-Agent headers, and
get_default_terminal() is not really right, but neither was the
original code; add TODO comments in those functions.
When the user chooses "Background and Notify", associate the download
with the terminal where the dialog box is. So any later messages will
then appear in that terminal, if it is still open. However, don't
change the terminal if the download has an external handler.
When a download gets some data, don't immediately check the associated
terminal. Instead, wait for the download to end. Then, if the
terminal of the download has been closed, use get_default_terminal()
instead. If there is no default terminal either, just skip any
message boxes.
make_bittorrent_peer_connection() used to construct a struct uri on
the stack. This was hacky but worked nicely because the struct uri
was not really accessed after make_connection() returned. However,
since commit a83ff1f565, the struct uri
is also needed when the connection is being closed. Valgrind shows:
Invalid read of size 2
at 0x8100764: get_blacklist_entry (blacklist.c:33)
by 0x8100985: del_blacklist_entry (blacklist.c:64)
by 0x80DA579: complete_connect_socket (socket.c:448)
by 0x80DA84A: connected (socket.c:513)
by 0x80D0DDF: select_loop (select.c:297)
by 0x80D00C6: main (main.c:353)
Address 0xBEC3BFAE is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
To fix this, allocate the struct uri on the heap instead, by
constructing a string and giving that to get_uri(). This string
cannot use the "bittorrent" URI scheme because parse_uri() does not
recognize the host and port fields in that. (The "bittorrent" scheme
has protocol_backend.free_syntax = 1 in order to support strings like
"bittorrent:http://beta.legaltorrents.com/get/159-noisome-beasts".)
Instead, define a new "bittorrent-peer" URI scheme for this purpose.
If the user attempts to use this URI scheme, its handler aborts the
connection with an error; but when make_bittorrent_peer_connection()
uses a bittorrent-peer URI, the handler is not called.
This change also lets get_uri() set the ipv6 flag if peer_info->ip is
an IPv6 address literal.
Reported by Witold Filipczyk.
