Re: [Emacs-diffs] master 5b5f441: read_key_sequence: correct the handling of raw_keybuf in recursive calls

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Mon, Nov 20, 2017 at 15:09:45 -0500, Stefan Monnier wrote:
> >> >  	    /* Calling read_char with COMMANDFLAG = -2 avoids
> >> >  	       redisplay in read_char and its subroutines.  */
> >> >  	    key = read_char (prevent_redisplay ? -2 : NILP (prompt),
> >> >  		             current_binding, last_nonmenu_event,
> >> >                               &used_mouse_menu, NULL);
> >> > +            raw_keybuf_count = outer_raw_keybuf_count;
> >> > +            raw_keybuf = outer_raw_keybuf;
> >> But here I worry: what if `read_char` exits non-locally because of
> >> a signal or a throw?
> > raw_keybuf{,_count} should then be re-initialised in command_loop_1 to
> > the static buffer variables, just before the call to read_key_sequence.

> But this `read_char` is within read_key_sequence: this read_key_sequence
> may have been called from anywhere, ....

read_key_sequence is static in keyboard.c, and is called from precisely
three places: command_loop_1, read_key_sequence_vs, and
read_menu_command.

> .... so after we exit it (non-locally), we may end up running
> arbitrary Elisp code before we return to command_loop_1, can't we?

Is it possible to exit non-locally from read_char (or one of its called
subroutines)?  I don't think read_char calls any lisp, even when it's
dealing with a menu.

> And during this time we'll have raw_keybuf pointing to an out-of-date
> stack location, which seems eminently dangerous.

You have a point, here.  Perhaps it would be better to get storage from
the Emacs heap rather than using the stack.

> I think we need to setup an unwind protection of some kind.

You might be right, but I'm not convinced yet.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).