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 ]
This is a further precaution against reading a pointer from the wrong
type of object. All of the JS_GetPrivate calls were already protected
with JS_InstanceOf checks if assertions are enabled, and many of them
also if assertions are not enabled.
[ Backported from commit 99f648b911 in
ELinks 0.12.GIT. --KON ]
Remember the index of struct form_state in vs->form_info
instead of the pointer to it. The pointer may change,
the index is persistent.
The field ecmascript_obj of the struct form_state is unused.
[ Backported from commit ecc03ad608 in
ELinks 0.12.GIT. --KON ]
screen_driver_change_hook was comparing only strlen(name) characters
and ignoring the '\0'. To reproduce the bug in ELinks 0.11.3 and
ELinks 0.12.GIT:
- Run TERM=screen elinks.
- In another terminal, run TERM=scr elinks. Quit this slave ELinks.
- Open the terminal options dialog and set 16 colors.
- Open the option manager and change the terminal.scr.colors option to
1 and back to 0.
- Note that ELinks no longer displays colors.
That bug could be fixed just by using len+1 instead of len. However,
there is also another bug: memcmp may compare the specified number of
bytes, even if some of the earlier ones differ; thus, it could in
principle read past the end of the malloc block and thereby crash
ELinks. Using strcmp may be a little slower but I do not believe it
could become a bottleneck.
[ Backported from commit f6f5eeceb7 in
ELinks 0.12.GIT. --KON ]
