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 e887efc611 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.
Introduce get_opt() to do the tedious work of getting the right
argument for options expecting them and handles both '--opt=arg'
and '--opt arg'. As a side effect it also removes an unneeded
assignment of the source string for stdin.
Works with both bash and dash. This reintroduces the fix to the
test-sgml-parser-basic test, and also fixes test-sgml-parser-incremental
and test-sgml-parser-lines, which Witek has reported as failing.
Use it for the actual I/O only. Previously, defining CONFIG_UTF8 and
enabling UTF-8 used to force many strings to the UTF-8 charset
regardless of the terminal charset option. Now, those strings always
follow the terminal charset. This fixes bug 914 which was caused
because _() returned strings in the terminal charset and functions
then assumed they were in UTF-8. This reduction in the effects of
UTF-8 I/O may also simplify future testing.
A problem with \n replacement caused test no. 19 to fail.
Fix it by also allowing expected output to be prepared in a
file by introducing a new backend: test_output_equals_file,
also used test_output_equals.
Tested on Ubuntu Feisty Fawn with both /bin/bash and /bin/sh
where /bin/sh failed before the fix. Reported by Witek.
Don't look for gettext message catalogs in ../po/ unless ELinks is being
run as src/elinks, ./src/elinks, or .../src/elinks.
Discovered by Arnaud Giersch, this alternate fix (than what is in debian
package 0.11.1-1.4) closes debian bug #417789 and redhat bug #235411.
Also reported in: CVE-2007-2027.
Restricting it to only work with --enable-debug was also considered,
however, it is an important feature for translaters so this less
paranoid fix was chosen.
Revert commit 2d6840b9bd9d3a7a45a5ad92b4e98ff7224d6d97. It is causing
passive FTP via IPv6 to fail on ftp.funet.fi. ELinks sends PASV and
the server says "425 You cannot use PASV on IPv6 connections. Use EPSV
instead."
Because the renderer no longer does that.
The comment "We don't cope well with entities here" may now be
obsolete but I'm not sure about that so I'm leaving it in.
options->cp is still used for this in seven places where html_context
is not easily available. Those should eventually be corrected too,
but I'm checking this change in already because it's better than what
we had before.
Previously, html_special_form_control converted
form_control.default_value to the terminal charset, and init_form_state
then copied the value to form_state.value. However, when CONFIG_UTF8
is defined and UTF-8 I/O is enabled, form_state.value is supposed to
be in UTF-8, rather than in the terminal charset.
This mismatch could not be conveniently fixed in
html_special_form_control because that does not know which terminal is
being used and whether UTF-8 I/O is enabled there. Also, constructing
a conversion table from the document charset to form_state.value could
have ruined renderer_context.convert_table, because src/intl/charsets.c
does not support multiple concurrent conversion tables.
So instead, we now keep form_control.default_value in the document
charset, and convert it in the viewer each time it is needed. Because
the result of the conversion is kept in form_state.value between
incremental renderings, this shouldn't even slow things down too much.
I am not implementing the proper charset conversions for the DOM
defaultValue property yet, because the current code doesn't have
them for other string properties either, and bug 805 is already open
for that.
I am going make fc->default_value use the charset of the document, and
recoding the string from the form history to that might lose characters.
This change also affects what ECMAScript sees in the defaultValue property.
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-26091157>
says it should represent the HTML "value" attribute, so changing it
based on form history is not appropriate.
This does not yet fix bug 947 for the case where the document is UTF-8
and the terminal is ISO-8859-1. That will require changing charsets.c
too, it seems.
Give them a corresponding Content-Type header. This must go in
cached->head because cached->content_type is supposed to be just
type/subtype. It will also be deduced from cached->head, so don't set
it separately.
Old versions of add_string_to_string returned the target string
unmodified if from->source pointed to a null character, which usually
meant that the source string was empty. That was changed in commit
5e18576391f75ad84e04f9c8a30b93d08f0b92ab on 2004-11-03 so that
add_string_to_string instead returned NULL in that situation. The
change seems to have been inadvertent.
I'm now reverting that change and also making add_string_to_string
check the emptiness of the source string based on the stored length
only, rather than on any null characters. So the function can now
also be used with non-C strings containing embedded null characters.
Note that the previous version did not completely prevent embedded
null characters either, because it checked only the first character.
trim_chars was called only in debug mode and the results of the get_attr_val
for value=" something " in debug mode differ from normal and fastmem mode.
[ From commit c4500039b2 on the witekfl
branch. --KON ]
The code works both with copiousoutput and without it.
[ Part 1/2 of commit c25c41bd18 on the
witekfl branch. I'm leaving out the part that depends on commit
469481b272, which is not yet safe to
apply. --KON ]
the handler reads data from stdin. I think it only works with copiousoutput.
[ Part 1/2 of commit 4a7b9415e1 on the
witekfl branch, fixes bug 916. I'm leaving out delayed_goto_uri()
for now because I don't understand its purpose. --KON ]
string_concat reads the args with va_arg(ap, const unsigned char *),
and the NULL macro may have the wrong type (e.g. int).
Many places pass string literals of type char * to string_concat.
This is in principle also a violation, but I'm ignoring it for now
because if it becomes a problem with some C implementation, then so
will the use of unsigned char * with printf "%s", which is so
widespread in ELinks that I'm not going to try fixing it now.
straconcat reads the args with va_arg(ap, const unsigned char *),
and the NULL macro may have the wrong type (e.g. int).
Many places pass string literals of type char * to straconcat. This
is in principle also a violation, but I'm ignoring it for now because
if it becomes a problem with some C implementation, then so will the
use of unsigned char * with printf "%s", which is so widespread in
ELinks that I'm not going to try fixing it now.
Previously, print_xml_entities did look up the charset, but did not
save the result anywhere and just used 0, leading to further lookups
in subsequent calls. It worked by accident though, because the
codepage index of us-ascii currently is 0.
Revert commit 2380ea9f1b,
"menu_leds_info: Don't call msg_text." MSGBOX_SCROLLABLE requires
a modifiable copy of the string, and msg_text provides that. To
reproduce the crash, run ELinks in a small window, select the English
language, and choose Help -> LED indicators.
Don't cast function pointers; calling functions via pointers of
incorrect types is not guaranteed to work. Instead, define the
functions with the desired types, and make them cast the incoming
parameters. Or define wrapper functions if the return types don't
match.
really_exit_prog wasn't being used outside src/dialogs/menu.c,
and I had to change its parameter type, so it's now static.
Revert commit 11e6aa8d97.
It is not useful to complicate the code to free the memory,
because the process is soon going to exit, and it has inherited
a lot more memory allocations from its parent.
The libsmbclient 3.0.10 compatibility changes are good though.
I'll re-apply them soon enough.
FSP v2 uses 32-bit file offsets in its UDP packets and cannot get past
4 GiB. ELinks should however try not to wrap the numbers to negative
at 2 GiB, if it is built with large file support.
Cast the parameters of the function instead. The C standard does not
guarantee that a function can be properly called via a pointer of a
different type.
Empty files were causing 'read from socket' errors.
[ This is half of commit eef1c17dce
from the witekfl branch. The SMB half is in commit
916b5cf545. --KON ]
This probably does the wrong thing with non-ASCII characters.
That's just because libsmbclient does not document which charset
it uses: it even reads smb.conf, which then may affect the choice.
Revert commit 5f36ad302e,
"Decompression: write PIPE_BUF bytes to the pipe at once if possible."
Without this reversion, <http://blogs.msdn.com/> displays as garbage.
It has Content-Encoding: gzip and Transfer-Encoding: chunked.
When tables were rendered first time html_format_part was called with
document==NULL. <meta http-equiv=Refresh.../> was inside a table,
so document was NULL. Second time the table knew its dimensions
and document was not NULL.
This function was unused and only the dummy backend implemented it
correctly. Fixing bug 534 will probably require adding this function
back again, but I think it will be easier to do it from scratch than
fix the bogus implementations we had here.
In goto_mark, copy the current_link of the old view state to the
old_current_link of the new view state so that clear_link will properly
clear the highlight for that link.
This fixes a bug introduced with the removal of link_bg in commit
c91c763d49.
Normally, the success msgbox is shown only if the ui.success_msgbox
option is set as 1, and clicking "Do not show anymore" would then
toggle the option to 0, and no more such msgboxes would appear.
However, if there already are two success msgboxes being displayed
(most likely in different terminals), then clicking "Do not show
anymore" in the first of them would reset the option to 0, but doing
the same in the second of them would toggle the option back to 1.
Rename toggle_success_msgbox to disable_success_msgbox, and make it
always reset the option to 0, regardless of the previous value.
This change allows screen_driver_change_hook to detect that the
charset has been changed to UTF-8 and set screen_driver.utf8 = 1.
redraw_screen then calls get_screen_driver, which propagates the flag
to terminal.utf8. That in turn avoids an assertion failure in
handle_interlink_event.
The previous code just printed time_t directly with "%ld". Now it
instead first casts to time_print_T (currently long) and then formats
with TIME_PRINT_FORMAT (currently "ld"). So the varargs will now
always match with the format string, even if time_t is longer than
long. This still doesn't correctly format time_t values larger than
LONG_MAX, though. But now it is at least easier to find some of the
places that need to be changed to support that.
I located these time_t-to-string conversions by searching for
str_to_time_t, expires, and last_visit. There are still more places
that assume every interesting time_t value fits either in 32 bits or
in a long, e.g. in the cookie editor and in the ECMAScript interface.
Inspired by bug 6.
* Recompute the pos variable for each cell, rather than just once per line.
This fixes the bug that only the first cell was being examined.
* Moved the bulk of the code outside the "if (frame && data >= 176 &&
data < 224)" conditional. This fixes the bug that only frame
characters were being added to the string.
* If the cell has UCS_NO_CHAR in it, don't add that to the string.
* Call encode_utf8 even for characters that originated from a frame.
This does not matter yet but will be correct if the function is
later changed to use the Unicode line-drawing characters for frames.
In the elinks.conf.5 manual page, the text below the list of modes was
getting included in the last list item. This appears to be a design
error in AsciiDoc. Work around it by moving the text above the list.
This ensures that no other string can have the same address. It
probably never was a problem though, because the strings to which it
can be compared either are allocated from the heap or are in
strings[][] which already has unshared storage.
On Dec 31, 2006, at 11:30am, Kalle Olavi Niemitalo writes:
>src/scripting/python/hooks.c (script_hook_url) calls hooks as
>goto_url_hook(new-url, current-url) and follow_url_hook(new-url).
>It has a comment saying that the current-url parameter exists
>only for compatibility and that the script can instead use
>elinks.current_url(). However, the current-url parameter was
>added in commit 87e27b9b3e and is
>not in ELinks 0.11.2, so any compatibility problems would only
>hit people who have been using 0.12.GIT snapshots. Can we remove
>the second parameter now before releasing ELinks 0.12pre1?
The decision isn't up to me, but I think this is a good idea. Here's a
patch that would update the documentation and hooks.py, as well as hooks.c.
FYI, if this patch is applied then anyone who's still trying to use a
goto_url_hook that expects a second argument will get a "Browser scripting
error" dialog box that says:
An error occurred while running a Python script:
TypeError: goto_url_hook() takes exactly 2 arguments (1 given)
As commit 7db8abf6e7 does for Lua
and the document info box, change the Python scripting backend's
current_document and current_header APIs to use document->cached
instead of find_in_cached so the currently displayed document
will be used rather than the latest version of the document.
The numbering of document.dump.color_mode and terminal._template_.colors
is now the same regardless of compile-time options, unlike in previous
versions. Therefore this version of ELinks may interpret a configuration
file differently from previous versions even if compiled with the same
options. This is unfortunate but the alternatives (keeping the numbering
dependent on configuration options; defining separate options that use
the new numbering; starting the numbers from 10 or so and recognizing the
previous ones only for compatibility) seem even worse.
This does not conflict with querying the palette from xterm (bug 890)
because although those palettes would have to be modifiable, they
would be terminal-specific rather than global.
