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.
These are the same functions whose argument strings xgettext should
add to elinks.pot. I also searched for uses of the functions that are
known to take format strings, in case the callers might take the
format string from the result of another function, but didn't find any
new ones.
I constructed the list by grepping for "..." and looking for related
macros and va_list functions. Also grepped for "*fmt", and "*format"
but the extra functions found that way (add_date_to_string,
format_command, subst_user_agent, etc.) handle format strings that
don't have the same syntax as in printf: in particular, type safety
does not depend on the order of format specifiers like it does in
printf. Therefore, these format strings should not be subjected to
the "c-format" checks of msgfmt.
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.
