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.
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.
