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.
The build ID now includes both last tagged version, commit generation
since last tagged version, as well as the leading characters of the
commit ID and a flag for dirty working tree.
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.
Today on the elinks-dev mailing list, the new maintainer of the Debian
elinks package asked the debian directory to be removed from released
tarballs, because it makes the Debian diff hard to read. Also, the
files there are out of date.
When the debian directory was discussed in April 2007, people didn't
want it to be removed, so I instead moved it to contrib/debian in
ELinks 0.12.GIT (599cf3d91e).
And now I'm doing the same in 0.11.3.GIT.
AsciiDoc 8 has changed the syntax again and generates e.g. subscripts
where we don't want them. Instead of updating the documents, I'll
just enable a compatibility mode so that ELinks doesn't require
AsciiDoc 8 yet.
On machines where sizeof(size_t) > sizeof(int), this could corrupt the stack.
I think -Wno-pointer-sign added by configure hid this bug until now.
STRLEN is correct in Perl 5.6.0 and later, perhaps earlier too.
<http://www.wikipedia.org/w/wiki.phtml?search=sue%20lawley>
incorrectly redirects to
<http://en.wikipedia.org/w/wiki.phtml?search=sue%2520lawley>
which searches for "sue%20lawley" rather than "sue lawley".
By using en.wikipedia.org directly, we avoid the server bug.
Prompted by an elinks-users post on 2007-07-27.
I asked on #wikimedia-tech, and www.wikipedia.org does always
redirect to en.wikipedia.org; it does not guess any other
language based on headers or IP addresses or such. Also, the
redirection exists only for compatibility, and skipping it
avoids a few roundtrips to the server. So this change is good
even if the server is eventually fixed.
(cherry picked from commit fd902e81da)
The Free Software Foundation has distributed the GNU gettext manual
under at least two different licenses (a brief copyleft and GNU FDL),
but neither of those seems compatible with the GPLv2 of ELinks.
(cherry picked from commit 9c1873a517)
The history converted from CVS is not in repo.or.cz though, so keep
referring to pasky.or.cz for that. (We don't seem to use
"gitweb.elinks.cz", which is a DNS alias for pasky.or.cz.)
<paakku> Do you think we should maybe point people to gitweb at
repo.or.cz rather than pasky.or.cz?
<pasky> absolutely
<pasky> actually I thought we already are pointing people at
repo.or.cz
<pasky> at least there was some movement to do that already, I believe
:)
[ From commit 9f75e1f094 in ELinks
0.12.GIT. --KON ]
Revert commit 5a49b9f14d of 2007-05-28,
"NEWS: mention bug 951", which was reverted in commit
f553679336 on 2007-05-30.
It is now safe to apply because bug 956 has been fixed.
Reapply commit 644908c130 of 2007-05-28,
"Garbage-collect SMJS objects before flushing caches." which was reverted
in commit 6cd6a843d1 on 2007-05-30.
It is now safe to apply because bug 956 has been fixed.
Add ecmascript_interpreter.backend_nesting, increment it when
beginning to evaluate an expression, and decrement it when evaluation
finishes. Then assert that it is zero in ecmascript_put_interpreter.
This detects bug 957 and similar ones before they corrupt memory.
[ Backported from commit 58e3ebf2e7 in
ELinks 0.12.GIT. --KON ]
The previous code cast the integer (long actually) to void * and gave
that to JS_SetPrivate. This did not work because JS_SetPrivate
expects pointers to be aligned and replaces the least significant bit
with a tag.
[ From attachment 379 of bug 755. This is less clean than attachment
380 (aka commit 871a1befad in ELinks
0.12.GIT) but avoids the need to raise the SpiderMonkey version
requirement in the ELinks 0.11 stable branch. --KON ]
