With Autoconf 2.60a, the default values of datadir, infodir, and
mandir refer to ${datarootdir}. If Makefile.config.in does not define
datarootdir, Autoconf detects this and expands ${datarootdir} when it
substitutes expressions like @datadir@, but it also outputs the
following warning:
config.status: creating Makefile.config
config.status: WARNING: /home/Kalle/src/elinks/Makefile.config.in seems to ignore the --datarootdir setting
According to a comment in config.status, "This hack should be removed
a few years after 2.60." So it seems best to prepare for that now by
defining datarootdir = @datarootdir@ in Makefile.config.in. Earlier
versions of Autoconf may leave that line unexpanded; but because the
makefiles do not directly refer to ${datarootdir}, there's no harm.
(cherry picked from commit 388b1b0efd)
Use the localedir variable so configure's --localedir option is
honoured. Expand the variable twice to first expand the datadir
and then the prefix variable referenced by datadir.
Noticed by Witold, who also made a similar fix (modulo --localedir)
in elinks-0.12 098fb87065.
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.
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.
