This patch changes normalize_uri() to no replace "//" with "/" in URIs. This
fixed this bug but will also lead to possibility that duplicate entries can
exist in ELinks' cache. ELinks might be able to detect in another way by
hashing the content or something.
[ From attachment 310 of bug 744. --KON ]
And add a prominent notice as stipulated in GNU GPL version 2 section 2a.
[ From commit ba54124f169a1c8506a11437d01c77c382bbe161 in ELinks
0.11.3.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. By using JS_SetReservedSlot instead, we get control of
the jsval conversions and can store the integer properly.
Revert part of commit 7215c964e40afe953787d7831b04182fbaba4662,
"Use real types (enum connection_{state,priority})." of 2005-06-14.
connection.pri[] is indexed by enum connection_priority, but its
elements are merely reference counts; they are never assigned from
or compared to enum connection_priority. Defining the elements
as int will result in more readable output from GDB.
Noted in bug 920.
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.
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
:)
And reorder the characters in the string given to strcspn(), to match
their expected order in the URI. This is also how strcspn() is called
elsewhere in uri.c.
Although <see/object.h> of SEE 2.0.1131 has a comment saying that
SEE_objectclass.enumerator is optional and may be left NULL, SEE
crashes if one tries to enumerate the properties of an object created
from such a class. Conveniently, it provides a suitable stub function.
http://www.adaptive-enterprises.com.au/bugs/show_bug.cgi?id=75
I don't remember why I cleared "returns", but it doesn't work
with www.hypermedia.pl/altkom/ and probably with many more sites.
[ From commit e887efc611cc64dd81e197ec419cec1373b157cf on the witekfl
branch. --KON ]
Scripts such as onsubmit are called as a function not as a script.
[ From commit 688ca8cf31c33b83e2cb9d4ddeaade97edfd6f59 on the witekfl
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.
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.
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.
