In almost all calls to parse_header, the second argument is a string
literal: parse_header(head, "Charset", NULL) for example.
Of course, parse_header does not write to that string. Accordingly,
make the parameter point to const, so calls that use a variable rather
than a string literal can make that variable point to const too.
Leaving the other parameters non-const for now.
http_negotiate_parse_data passed &token->length as the int *outlen
parameter of base64_decode_bin, which stores an int at that location.
However, gss_buffer_desc::length is size_t in all implementations that
I checked: MIT Kerberos Version 5 Release 1.10, libgssglue 0.4, and
GNU GSS 1.0.2. This mismatch could cause the build to fail:
.../src/protocol/http/http_negotiate.c: In function ‘http_negotiate_parse_data’:
.../src/protocol/http/http_negotiate.c:173:2: error: passing argument 3 of ‘base64_decode_bin’ from incompatible pointer type [-Werror]
In file included from .../src/protocol/http/http_negotiate.c:30:0:
.../src/util/base64.h:8:16: note: expected ‘int *’ but argument is of type ‘size_t *’
On 64-bit big-endian hosts, it might also cause the GSSAPI
implementation to read too much data from memory and disclose it to
some network server, or crash ELinks.
(cherry picked from elinks-0.12 commit d33c807dd97ddab534b22bd4ad3c93b44fbd5916)
I had already done this to my other scripts on 2008-09-28 (commit
c67885d880aa6be98c53f6d682368b23c3faff01) but missed Unicode/gen-case.
Update it, and list it in COPYING.
(Although Unicode/gen-case is part of the source tree, this version of
ELinks does not use that file for anything.)
(cherry picked from elinks-0.12 commit c7602eb7444f42bf07286e31bb73022995cabf4b)
unregister_options() requires as a sentinel an instance of struct
option where option.name is NULL. However, the NULL_OPTION_INFO macro
used for these sentinels actually initializes a struct option_init
instead. Make register_options() overwrite the NULL_OPTION_INFO with
a sentinel in the correct format. This probably makes a difference
only on platforms where null pointers don't have all bits zero.
(cherry picked from elinks-0.12 commit 8ac10e00d4cd7b3cdd1030d29abaca77f9886c35)
l_set_option() was passing the address of an int to
option_types[OPT_INT].set and option_types[OPT_BOOL].set.
That looks correct but is not: both function pointers
point to num_set(), which actually reads *(long *) str.
Change l_set_option() to pass the address of a long instead,
and add comments about this dependency.
(cherry picked from elinks-0.11 commit 8766e3829f4156fca541bc01784c4fdf46a89dad)
(cherry picked from elinks-0.12 commit 0797f04921f5fb2dada86d53b7655adf634751f5)
ELinks already allowed '+' and '*' in the names of options when
reading a configuration file. The option manager however didn't
let the user add such options. Allow the characters there too.
These characters are needed especially in the mime.type tree,
where '*' is used as a replacement for '.'. For example:
set mime.type.audio.prs*sid = "sid"
set mime.type.application.atom+xml = "atom"
This commit changes one gettextised string.
(cherry picked from elinks-0.12 commit 064ff3921d9e06d55272bc17bb8dfa9ee5c671d3)
No changes in program logic or data layout.
(cherry picked from elinks-0.12 commit 972afa1c26d2f01575d9964aebd6ead1f62d38f2)
Conflicts:
src/config/options.c:
0.13.GIT has a new function get_option_shadow, now
doxygenized likewise.
INIT_OPTION used to initialize union option_value at compile time by
casting the default value to LIST_OF(struct option) *, which is the
type of the first member. On sparc64 and other big-endian systems
where sizeof(int) < sizeof(struct list_head *), this tended to leave
option->value.number as zero, thus messing up OPT_INT and OPT_BOOL
at least. OPT_LONG however tended to work right.
This would be easy to fix with C99 designated initializers,
but doc/hacking.txt says ELinks must be kept C89 compatible.
Another solution would be to make register_options() read the
value from option->value.tree (the first member), cast it back
to the right type, and write it to the appropriate member;
but that would still require somewhat dubious conversions
between integers, data pointers, and function pointers.
So here's a rather more invasive solution. Add struct option_init,
which is somewhat similar to struct option but has non-overlapping
members for different types of values, to ensure nothing is lost
in compile-time conversions. Move unsigned char *path from struct
option_info to struct option_init, and replace struct option_info
with a union that contains struct option_init and struct option.
Now, this union can be initialized with no portability problems,
and register_options() then moves the values from struct option_init
to their final places in struct option.
In my x86 ELinks build with plenty of options configured in, this
change bloated the text section by 340 bytes but compressed the data
section by 2784 bytes, presumably because union option_info is a
pointer smaller than struct option_info was.
(cherry picked from elinks-0.12 commit e5f6592ee20780a61f70feeb1f9e17631b9c5835)
Conflicts:
src/protocol/fsp/fsp.c: All options had been removed in 0.13.GIT.
src/protocol/smb/smb2.c: Ditto.
po/README suggests running the po/gen_translations_stats.sh script,
and it has a #! line, so it should be executable.
(cherry picked from elinks-0.12 commit 70ef4c8fddec397c29d267133b61db8a8604d305)
http://buildd.debian-ports.org/fetch.php?pkg=elinks&arch=hurd-i386&ver=0.12%7Epre5-1&stamp=1247378205&file=log&as=raw
shows two unsightly errors, apparently triggered by TERM=unknown:
tput: unknown terminal "unknown"
/build/buildd/elinks-0.12~pre5/configure: line 25480: test: -ge: unary operator expected
Hide the first of them by redirecting to /dev/null,
and avoid the second one by substituting "0" if tput fails.
I'm not sure why `which tput` is used instead of plain tput,
but it doesn't seem to be causing any problems in practice.
(There are problems in theory if tput is not installed,
tput is found in a directory whose name contains spaces,
or tput is a shell function or builtin.)
(cherry picked from elinks-0.12 commit 4369b052ef2e47d89487a566386a0e8faceecc1c)
Fix this GCC 3.4.6 warning, which becomes an error
if configure --enable-debug adds -Werror to CFLAGS:
[CC] src/document/css/apply.o
In file included from /home/Kalle/src/elinks-0.12/src/document/html/internal.h:6,
from /home/Kalle/src/elinks-0.12/src/document/css/apply.c:35:
/home/Kalle/src/elinks-0.12/src/document/html/parser.h:149: warning: parameter has incomplete type
In file included from /home/Kalle/src/elinks-0.12/src/document/css/apply.c:35:
/home/Kalle/src/elinks-0.12/src/document/html/internal.h:125: warning: parameter has incomplete type
Even without this warning, "enum html_special_type;"
would not be standard C89.
(cherry picked from elinks-0.12 commit c9f487cdf44c97948559d882f7b59e37b51cd7af)
Conflicts:
src/document/html/parser.h: 0.13.GIT had more #includes already.
Call get_window_title() at most once per terminal, even if it fails.
If ELinks is configured with X11 support, get_window_title() calls
XOpenDisplay(), which can sleep if $DISPLAY does not respond.
This delay was previously incurred every time ELinks changed the
title. Besides, if ELinks had already changed the title, setting
ditrm->orig_title = get_window_title(); did not make sense anyway.
(cherry picked from elinks-0.12 commit 5d4beadc4b76f826f006fa951af4b24add12d4f6)
Conflicts:
src/terminal/kbd.c:
get_window_title has a codepage parameter in 0.13.GIT.
(cherry picked from elinks-0.12 commit 51dc3beee71e87bd254845591c95e378ba59970d)
Conflicts:
NEWS: Both 0.12pre5.GIT and 0.13.GIT had inserted a new section.
src/terminal/window.c: Both had inserted a new function.
... and mention that URI rewriting rules may leak ELinks' identity
in the documentation of protocol.http.user_agent.
Originally requested at <https://bugzilla.redhat.com/856348>.
This reverts commit d06cccffd60d75fa7c4782d5276006311258b5c6.
Some people wants URL in the title bar, but some wants the title.
I restored previous version (the title). If you want the URL, create
the patch with a configurable option.
The long term goal is good looking of the Python docs in ELinks, especially
background colors. Every start tag and every text node would have associated
a natural number. Those numbers would be "drawn" in the document instead
of colors. Finally, the screen driver would change numbers into colors.
This will be done in small steps. The next step is to implement this change
in the screen driver.
Add a case for CSS_LIST_ORDINAL (and assert(0)) to the switch in
css_apply_list_style. This change should eliminate a warning from the
compiler reported by Witold that CSS_LIST_ORDINAL is not handled.
