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 e5f6592ee2)
Conflicts:
src/protocol/fsp/fsp.c: All options had been removed in 0.13.GIT.
src/protocol/smb/smb2.c: Ditto.
If globhist_simple_search ran out of memory in stracpy(search_url), it
could leave gh_last_searched_title pointing to freed memory and cause
a crash in the next call. Fix by not freeing gh_last_searched_title.
It is then possible to have gh_last_searched_title and
gh_last_searched_url pointing to strings from different searches;
but that was already possible if stracpy(search_title) failed.
Because this bug occurs only in out-of-memory situations and I don't
think ELinks in general has been properly tested in those, the fix is
perhaps not worth mentioning in NEWS and backporting to elinks-0.11.
Documentation strings of most options used to contain a "\n" at the
end of each source line. When the option manager displayed these
strings, it treated each "\n" as a hard newline. On 80x24 terminals
however, the option description window has only 60 columes available
for the text (with the default setup.h), and the hard newlines were
further apart, so the option manager wrapped the text a second time,
resulting in rather ugly output where long lones are interleaved with
short ones. This could also cause the text to take up too much
vertical space and not fit in the window.
Replace most of those hard newlines with spaces so that the option
manager (or perhaps BFU) will take care of the wrapping. At the same
time, rewrap the strings in source code so that the source lines are
at most 79 columns wide.
In some options though, there is a list of possible values and their
meanings. In those lists, if the description of one value does not
fit in one line, then continuation lines should be indented. The
option manager and BFU are not currently able to do that. So, keep
the hard newlines in those lists, but rewrap them to 60 columns so
that they are less likely to require further wrapping at runtime.
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.
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.
Introduce a new list, global_history_reap_list, and a new routine,
reap_deleted_globhist_items, which deletes unused items from that
list. In done_global_history_item, do not free the item; just move it
to that list. Call global_history_reap_list in add_global_history_item
and free_global_history.
