get_keymap_id returns -1 when it can't find the keymap. Because the return
type of get_keymap_id is enum keymap_id and enum keymap_id did not have any
explicit values defined, it could be unsigned, which meant that when
get_keymap_id returned -1, it was really returning a huge positive number.
This meant that when callers checker whether the return value was negative,
they were essentially performing no check at all, so they might give
get_keymap_id an invalid keymap name, get back an invalid keymap_id, and
use that invalid keymap_id.
This commit adds KEYMAP_INVALID = -1 to enum keymap_id and makes all
functions that deal with the enumeration use that symbol.
get_keymap_id returns -1 when it can't find the keymap. Because the return
type of get_keymap_id is enum keymap_id and enum keymap_id did not have any
explicit values defined, it could be unsigned, which meant that when
get_keymap_id returned -1, it was really returning a huge positive number.
This meant that when callers checker whether the return value was negative,
they were essentially performing no check at all, so they might give
get_keymap_id an invalid keymap name, get back an invalid keymap_id, and
use that invalid keymap_id.
This commit adds KEYMAP_INVALID = -1 to enum keymap_id and makes all
functions that deal with the enumeration use that symbol.
Previously, struct string was used here. However,
bittorrent_fetch_callback does not initialize response.magic,
and parse_bittorrent_tracker_response changes response->source
to point to data that must not be freed. So the util/string.h
functions are not actually safe to use on these objects.
For this reason, it is safer to use a separate type.
The previous check (integer > (off_t) integer * 10) did not detect all
overflows. Examples with 32-bit off_t:
integer = 0x1C71C71D (0x100000000/9 rounded up);
integer * 10 = 0x11C71C722, wraps to 0x1C71C722 which is > integer.
integer = 0x73333333;
integer * 10 = 0x47FFFFFFE, wraps to 0x7FFFFFFE which is > integer.
Examples with 64-bit off_t:
integer = 0x1C71C71C71C71C72 (0x10000000000000000/9 rounded up);
integer * 10 = 0x11C71C71C71C71C74, wraps to 0x1C71C71C71C71C74
which is > integer.
integer = 0x7333333333333333;
integer * 10 = 0x47FFFFFFFFFFFFFFE, wraps to 0x7FFFFFFFFFFFFFFE
which is > integer.
It is unclear to me what effect an undetected overflow would actually
have from the user's viewpoint, so I'm not adding a NEWS entry.
(cherry picked from commit a25fd18e56)
It is unlikely because the standard members of struct sockaddr_in
(sin_family, sin_port, sin_addr) already require at least 8 bytes
and I don't know of any system that has size_t larger than that.
Besides, at least glibc pads the structure to 16 bytes.
When get_pasv6_socket was merged into get_pasv_socket on 2005-04-15,
the AF_INET6 of get_pasv6_socket was lost and the merged function
always returned AF_INET sockets. This then made getsockname fill
only part of the struct sockaddr_in6, and ELinks sent to the server
an EPRT command that had half the bits missing from the IPv6 address.
At least ftp.funet.fi then rejected the command, helpfully saying
what the address should have been.
This commit fixes active FTP over IPv6. Passive FTP was already fixed
in 0.11.3.GIT (887d650efe), on 2007-05-01.
The output should be:
Two lines should be visible.
The second line.
All three tests fail currently when the ELinks is invoked like this:
$ elinks -no-connect path_to_chunked_test
The previous code displayed the wrong attributes if the combining
characters were at the end of an HTML link. For example:
<a href="#">trickỹ</a> more text <a href="#">second link</a>
(The characters in the first A element are "tricky" and U+0303
COMBINING TILDE.)
Here, when the cursor was not at the first link, ELinks displayed
the y-with-tilde cell as if it were not part of the link.
This happened because ELinks had already changed schar->attr
before set_line saw the space character after the link and
flushed document->combi[].
Combining characters requires a UTF-8 locale.
It slows down rendering. There is still the unresolved issue with
combining characters at the end of a document.
This patch wasn't heavilly tested. Especially a "garbage" input may cause
unpredictable results.
In the previous version, the first event that had KBD_MOD_PASTE
entered insert mode and was consumed for that; ELinks then inserted
the characters from the remaining events. Now, to make ELinks insert
the first character too, I'm changing things so that KBD_MOD_PASTE
does not cause insert mode to be entered; instead, ELinks inserts
those characters regardless of whether insert mode is on.
Since there is only one LED panel per terminal, redrawing for each session
is wasteful.
Furthermore, since one terminal can have many sessions (i.e. tabs), and
since the last session in the list might not be the current session, the
wrong LEDs might be drawn.
An easy way to demonstrate the bug is to enable ui.clock.enable, so that
the panel is redrawn every 100ms, and then to select a text field and enter
insert mode. Unless the current tab is the last tab, the insert-mode LED
will only briefly show that insert mode is enabled.
