From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 5b5f441: read_key_sequence: correct the handling of raw_keybuf in recursive calls Date: Mon, 20 Nov 2017 20:30:04 +0000 Message-ID: <20171120203004.GC3917@ACM> References: <20171120181209.23553.97060@vcs0.savannah.gnu.org> <20171120181210.7946F20416@vcs0.savannah.gnu.org> <20171120195918.GB3917@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1511210011 16348 195.159.176.226 (20 Nov 2017 20:33:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2017 20:33:31 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 20 21:33:25 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGskt-0003lz-5W for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2017 21:33:23 +0100 Original-Received: from localhost ([::1]:59622 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGsl0-0002LX-99 for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2017 15:33:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGskp-0002K0-PZ for emacs-devel@gnu.org; Mon, 20 Nov 2017 15:33:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGskm-0005ot-MK for emacs-devel@gnu.org; Mon, 20 Nov 2017 15:33:19 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:58515 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eGskm-0005nQ-FQ for emacs-devel@gnu.org; Mon, 20 Nov 2017 15:33:16 -0500 Original-Received: (qmail 65067 invoked by uid 3782); 20 Nov 2017 20:33:14 -0000 Original-Received: from acm.muc.de (p548C744B.dip0.t-ipconnect.de [84.140.116.75]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 20 Nov 2017 21:33:14 +0100 Original-Received: (qmail 25679 invoked by uid 1000); 20 Nov 2017 20:30:04 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220313 Archived-At: 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).