Commit 2b95a8ef authored by Paul Eggert's avatar Paul Eggert

* keyboard.c (read_decoded_event_from_main_queue): Reinstitute alloca

here for destination buffer, to work around what appears to be a
bug in decode_coding_c_string when the source and destination are
both C strings.

* keyboard.c (echo_add_key, menu_bar_items, tool_bar_items)
parent d3cb31cb
2014-09-07 Paul Eggert <eggert@cs.ucla.edu>
* keyboard.c (read_decoded_event_from_main_queue): Reinstitute alloca
here for destination buffer, to work around what appears to be a
bug in decode_coding_c_string when the source and destination are
both C strings.
Use SAFE_ALLOCA etc. to avoid unbounded stack allocation (Bug#18410).
This follows up on the recent thread in emacs-devel on alloca; see:
http://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00042.html
......@@ -24,7 +29,8 @@
* ftfont.c (ftfont_get_charset, ftfont_check_otf, ftfont_drive_otf):
* ftxfont.c (ftxfont_draw):
* image.c (xbm_load, xpm_load, jpeg_load_body):
* keyboard.c (echo_add_key, menu_bar_items, tool_bar_items):
* keyboard.c (echo_add_key, menu_bar_items, tool_bar_items)
* keymap.c (Fdescribe_buffer_bindings, describe_map):
* lread.c (openp):
* menu.c (digest_single_submenu, find_and_call_menu_selection)
......
......@@ -2362,7 +2362,14 @@ read_decoded_event_from_main_queue (struct timespec *end_time,
if (meta_key != 2)
for (i = 0; i < n; i++)
src[i] &= ~0x80;
coding->destination = dest;
/* FIXME: For some reason decode_coding_c_string requires a
fresh output buffer each time, and reusing the old buffer can
make Emacs dump core. Avoid triggering the problem for now
by allocating a new buffer each time through the loop. */
bool please_fixme = true;
coding->destination = please_fixme ? alloca (n * 4) : dest;
coding->dst_bytes = n * 4;
decode_coding_c_string (coding, src, n, Qnil);
eassert (coding->produced_char <= n);
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment