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 fd902e81dadc2f8bed76445acdd27e7eca5548d9)
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 9c1873a517db49aa95fbd831c81ea5005c65e3eb)
This tool is intended for developers to make debugging ELinks more fun.
[ From commit 4e310fd9aaa817e96887fd8e271f0221590a982b in ELinks
0.12.GIT. --KON ]
Commit 63752c854b303f5f58636a512a137bf3702e051b on 2004-12-27
seems to have broken this.
[ From commit c9b2fbbd46c35948c229b6bcfd65f1b9a5755056 in ELinks
0.12.GIT. --KON ]
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 9f75e1f094109ab10c473672484aa36bd4a01092 in ELinks
0.12.GIT. --KON ]
Revert commit 5a49b9f14d4b8bb30bfada4958c22e6a8cfab21e of 2007-05-28,
"NEWS: mention bug 951", which was reverted in commit
f55367933653b37a8d298697bccfdf462fb29cde on 2007-05-30.
It is now safe to apply because bug 956 has been fixed.
Reapply commit 644908c130210ed7b17a3bd1241244576b94c546 of 2007-05-28,
"Garbage-collect SMJS objects before flushing caches." which was reverted
in commit 6cd6a843d1592f8fe69370d33cc7f3a341d3531c 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 58e3ebf2e70bf228ab741a39bcaf99e61b0ffb3a 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 871a1befad3d9c37c59f228154d12fe37f594703 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 99f648b911d4199944314723d3f3e4f55b844b67 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 ecc03ad608cea63b89877935529b2881336852cd 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 f6f5eeceb75c4c034810486d558417cd23e09a54 in
ELinks 0.12.GIT. --KON ]
It was broken in 0.11.2.GIT (a64dd281e9169ebfea963ad64ec36e4c7782aa67).
Since then, $QUERY_STRING has been empty for <file:///foo/bar?query>.
uri.data is documented as containing both the path and the query.
[ Commit message by me. --KON ]
Revert commit 644908c130210ed7b17a3bd1241244576b94c546,
"Garbage-collect SMJS objects before flushing caches."
The extra garbage collections increase the risk of crashing because of
dangling pointers in form_state.ecmascript_obj. I don't think I'll
have time to properly document the bug and backport the fix before
the 0.11.4 release, so I'm reverting the change instead.
Revert commit 5a49b9f14d4b8bb30bfada4958c22e6a8cfab21e,
"NEWS: mention bug 951"
The extra garbage collections increase the risk of crashing because of
dangling pointers in form_state.ecmascript_obj. I don't think I'll
have time to properly document the bug and backport the fix before
the 0.11.4 release, so I'm reverting the change instead.
