GNU bug report logs - #68272
[PATCH] Fix -1 leaking from C to lisp in 'read-event' etc.

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Tim Ruffing <crypto@HIDDEN>; Keywords: patch; dated Fri, 5 Jan 2024 21:20:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 68272 <at> debbugs.gnu.org:


Received: (at 68272) by debbugs.gnu.org; 13 Jan 2024 17:40:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 13 12:40:41 2024
Received: from localhost ([127.0.0.1]:40981 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rOhzt-0007Oq-2g
	for submit <at> debbugs.gnu.org; Sat, 13 Jan 2024 12:40:41 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3057)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1rOhzr-0007Od-6W
 for 68272 <at> debbugs.gnu.org; Sat, 13 Jan 2024 12:40:39 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B3AA5440FD6;
 Sat, 13 Jan 2024 12:40:34 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1705167632;
 bh=8Iok5tK96sa5HVFYEPRBps5s9mueN9Bg70RfqNegJSU=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=NkvfwTzJ/X22lCKdSQUvM89KPfnXpmnI7GhGwyh1WJ+4v/grAF7OoHBu09ckw6A6F
 vE05EJvZn3EmgztvGqcsSSDxT5v+9f7iqNY3g118X0O6eN5qgho6z0UgxPlux3mv3V
 Kl1MPVUJR5YbuvyLs4K4nJES7vbX6O1PrhIdZoqacsDwg51LueiB8U7l/pyDdXo2At
 02OxnQmJXMT+i7hzImPg/BJpkcGu82qEkPisXwtpcIgLpZnqqhKE3oTJiK4tK4jI5g
 lN51w87jsmxvwIvQ1l3OYulW0jSORxdF9dnQTWgLc62GVCibFWyiBrkFL7IIuRs/zF
 M8ZqylpLnN1iQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A837B440B2E;
 Sat, 13 Jan 2024 12:40:32 -0500 (EST)
Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7C88812082B;
 Sat, 13 Jan 2024 12:40:32 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Tim Ruffing <crypto@HIDDEN>
Subject: Re: bug#68272: [PATCH] Fix -1 leaking from C to lisp in
 'read-event' etc.
In-Reply-To: <1b3fa12138838a3fe5643a9e76a65d32a677e34d.camel@HIDDEN>
 (Tim Ruffing's message of "Sat, 06 Jan 2024 15:32:23 +0100")
Message-ID: <jwvzfx9gp8n.fsf-monnier+emacs@HIDDEN>
References: <46480759b6d89b5a4864e8ee1b986817366a56e5.camel@HIDDEN>
 <83wmsmucuo.fsf@HIDDEN>
 <1b3fa12138838a3fe5643a9e76a65d32a677e34d.camel@HIDDEN>
Date: Sat, 13 Jan 2024 12:40:31 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.009 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 68272
Cc: Eli Zaretskii <eliz@HIDDEN>, 68272 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi Tim,

> Hey, thank you very much for the long email. I was somewhat prepared
> for hesitant reply, and I totally understand that "there be dragons".

:-)

> And I'm also aware that it doesn't spark confidence when someone with
> (almost) zero code contributions submits a patch of this kind.

[ Actually, such carefully written code and (even more so) the
  convention-abiding commit messages coming from someone who's not
  a regular contributor spiked my ears.  It made me think
  that this is either a carefully crafted trojan, or it's a really
  welcome new kid on the block :-)  ]

> First of all, I think the bug is real.

No doubt.  Bug#62018 brought to my attention to nasty situation, and I'm
really glad you went through the trouble to come up with a cleanup.

> But the problem is not just that this is not elegant.  It's worse
> because it's also pretty unclear what the caller should do in
> this case.

Yes, I think we should document in a comment somewhere how the end of
kmacro is handled from a "global" perspective: what `read_char`
does when it's the case, where/when it's supposed to be detected and how
this "signal" is propagated from there to the corresponding call to
`execute-kbd-macro`, how that relates to setting `executing-kbd-macro`
back to nil, ...

> One thing the caller can simply do is to error out.

My first intuition is that we should do that more often.
That's what `calc.el` does.

In `read-char-choice-with-read-key`, OTOH we apparently decided to
consider that not as an error but to "transparently" continue execution
past the end of the kmacro by reading from the keyboard (which
is the behavior that your patch implements).

In the case of `dbus.el` my head hurts trying to understand what the code
really does, really should do, and how your patch changes its behavior.
First, the `dbus.el` code is problematic in any case because it relies
on "pre-reading" input events and pushing them back on
`unread-command-events`, which is sadly not 100% "a no-op".  We should
provide better primitives to handle such parallel input streams
without having to "read" all events and them push them back.

IIUC, with your patch, we have the following scenario:
- Say we're inside a kmacro with N events left to execute.
- Dbus reads those N events and stashes them them onto `unread-command-events`.
- Dbus finally can read the actual dbus event and does its thing.
- Good!
- But now `at_end_of_macro_p` will return true, even though we've yet to
  execute the last N events.  We'll presumably still execute them
  (since they're in `unread-command-events`) but that won't be
  considered as coming from a kmacro any more.

> But if the caller wants an event, the only thing it can do is to touch
> executing_kbd_macro and set it nil explicitly (this is what subr.el
> does currently).

My head also hurts trying to understand what are the consequences of
doing that.

> We could also document this, but I feel something like
> "this function can return -1 and if it does, set executing_kbd_macro to
> nil and try again" is really a bit too unelegant (and it has more
> downsides, see next paragraph).

Agreed.  I think the problem is that we haven't clearly decided what
`execute-kbd-macro` is supposed to do.  The problem is that the way it's
expected to work implies a form of "nesting" such that at the end of
processing those events we return from the function, but sometimes
that's not what happens.  E.g. a kmacro can end in the middle of
a recursive edit.

Your patch brings is closer to a non-nesting semantics, a bit as if
`execute-kbd-macro` pushed all those events into the incoming input
queue and returned immediately.

Maybe that's what `execute-kbd-macro` should do, really: push all the
events into `unread-command-events` and return.  But then, how would we
do the boolean tests for `executing-kbd-macro` which we perform at
various places?  [ I guess we could label/wrap the events such that they
get executed in a special way (which let-binds `executing-kbd-macro` to
t?  ]

Seeing how `calc.el` used the -1 to signal an error (i.e. forcing
kmacros to contain "complete sequences"), maybe a half-way
behavior between the current one and your new one would be for
`read_char` to return -1 (or rather a more explicit `end-of-kbd-macro`)
event *once* and then on the next call to go on and read from
the keyboard.

> 3. commit: only change is that -1 is not propagated to lisp, other
> callers of read_char are unaffected as I explained above. (modulo
> Vlast_event_device and Vlast_event_frame -- which I can also still set
> if you want me to to).

"-1 is not propagated to lisp" doesn't say what happens in its stead.
What this does really is transparently continue reading input from the
keyboard when reaching the end of a kmacro.

I tend to agree that it's closer to the ideal behavior (even though
I still don't know what that is :-).


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#68272; Package emacs. Full text available.

Message received at 68272 <at> debbugs.gnu.org:


Received: (at 68272) by debbugs.gnu.org; 13 Jan 2024 09:40:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 13 04:40:35 2024
Received: from localhost ([127.0.0.1]:38448 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rOaVG-0008FL-Qu
	for submit <at> debbugs.gnu.org; Sat, 13 Jan 2024 04:40:35 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:54466)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1rOaVF-0008F9-81
 for 68272 <at> debbugs.gnu.org; Sat, 13 Jan 2024 04:40:34 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1rOaV3-0000bS-1c; Sat, 13 Jan 2024 04:40:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=e9AV3QT9Hcc8mOkZrQqzNMgY6QguXJDBMLne4JeS9oA=; b=h0nelmsdfvEOPDlfrX8D
 dkq7EOhuxmijD9NVrQSNWjG0BUOx11VSb0WJT7aUEAmmEadnvkeFoj53MRBT3CkOKTB6nlnh2Yaur
 imuUfq7edyX9E2/D6TTg/S4USpzsi6MjGOkZSdlSxxm0KlXyQFZIrDkFHdzpbsH5Z2GVq7THsISNS
 ESHspVTmNcjGfeQbUvenNvDlQsvZN4JkeDQnmxczO42WE8L8TijSSV+VObAd4cz14CQz0V6G3PoWN
 KSJU8vl7KLvU+vMJ8T6yGL6EZHETQdW/URqUwWQ7iQkwyPIKy36i7y7D4iiErZ4D+SZembX6BkyTR
 GFRJwpUm5aCaig==;
Date: Sat, 13 Jan 2024 11:39:29 +0200
Message-Id: <83cyu5h8ry.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Tim Ruffing <crypto@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <1b3fa12138838a3fe5643a9e76a65d32a677e34d.camel@HIDDEN>
 (message from Tim Ruffing on Sat, 06 Jan 2024 15:32:23 +0100)
Subject: Re: bug#68272: [PATCH] Fix -1 leaking from C to lisp in
 'read-event' etc.
References: <46480759b6d89b5a4864e8ee1b986817366a56e5.camel@HIDDEN>
 <83wmsmucuo.fsf@HIDDEN>
 <1b3fa12138838a3fe5643a9e76a65d32a677e34d.camel@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 68272
Cc: 68272 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan, any comments or ideas?

I'm not very comfortable with this change, frankly, and tend to
document this "feature" leaving the code alone.  Note that currently
various callers do different things when they get the -1 value, and it
is unclear to me whether changing that will be perceived as
regressions.

In any case, I think the patch needs a change, if only to account for
the fact that requeued_events_pending_p is called from process.c.

> From: Tim Ruffing <crypto@HIDDEN>
> Cc: 68272 <at> debbugs.gnu.org
> Date: Sat, 06 Jan 2024 15:32:23 +0100
> 
> Hey, thank you very much for the long email. I was somewhat prepared
> for hesitant reply, and I totally understand that "there be dragons".
> And I'm also aware that it doesn't spark confidence when someone with
> (almost) zero code contributions submits a patch of this kind. I feel
> the same when new people send complex patches to the C library I
> maintain... And sure, it took a me quite a while to navigate this maze
> of keyboard.c and to come up with this patch and make the tests pass,
> but I feel rather confident now that this is the right approach.
> 
> I agree, we can never be fully sure that this introduces regressions,
> but let me still try to convince you that this approach and these
> patches are carefully crafted and thought through. Here's my analysis
> of the situation:
> 
> First of all, I think the bug is real. read-event (and read-char and
> read-char-exclusive, which I won't mention from now on for brevity) can
> return -1, but the docs don't mention -1, and it's arguably a strange
> "magic" value for a lisp function. If anything, one would expect nil,
> or some special symbol. Of course, we could simply document the -1
> return value. 
> 
> But the problem is not just that this is not elegant. It's worse
> because it's also pretty unclear what the caller should do in this
> case. In particular, the caller can't simply skip the -1 and try again:
> The caller will see an infinite stream of -1 values, until the keyboard
> macro has been resolved properly, i.e., as long as executing_kbd_macro
> is non-nil. One thing the caller can simply do is to error out. But if
> the caller wants an event, the only thing it can do is to touch
> executing_kbd_macro and set it nil explicitly (this is what subr.el
> does currently). We could also document this, but I feel something like
> "this function can return -1 and if it does, set executing_kbd_macro to
> nil and try again" is really a bit too unelegant (and it has more
> downsides, see next paragraph).
> 
> However, this now hints at a different approach: Could we handle this
> in read-event locally and just perform the retrying for the caller?
> First of all, we'd probably still do it one level below in the call
> stack in order not to mess up with the timeouts (if we simply try
> again, we could double the timeout), so we'd want to do it
> inread_filtered_event. But I think that approach will then be *not*
> localized and thus dangerous: it's not clear if setting
> executing_kbd_macro to nil has unexpected side effects have. Resolving
> the macro properly is ultimately the responsibility of
> Fexecute_kbd_macro and pop_kbd_macro in macros.c, and we shouldn't just
> declare at some other point in the code that we wish the macro handling
> to be done.
> 
> -------------
> 
> Let me try to convince you that these commits are more harmless than
> they look at the first glance. I'll go through them one by one. I'm
> also happy to add a revised version of this to the commit messages.
> 
> 1. "Extract check for end of macro to function":
> This is pure refactoring. A brief code review shows that this does not
> change semantics at all.
> 
> 2. "src/keyboard.c (requeued_events_pending_p): Revive"
> 
> 2a.
> 
> On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> >   For example, your patches modify
> > requeued_events_pending_p, but that function is called in several
> > places, including outside of keyboard.c -- how can we be sure we are
> > not introducing regressions this way? 
> 
> Oh, good catch. In fact, it's (without the patches here) only called
> outside of keyboard.c. I was misled by the comment that said "This
> isn't used yet. The hope is to make wait_reading_process_output call
> it". Indeed, this comment is outdated and the (only) caller is
> wait_reading_process_output. wait_reading_process_output really wants
> only keyboard output, so it should really just check
> Vunread_command_events and not unread_post_input_method_events and
> Vunread_input_method_events; the latter two are for non-keyboard input.
> I can rework this. I think the way to go is to split this into two
> functions requeued_events_pending_p and
> requeued_command_events_pending_p or similar, and fix the outdated
> comment.
> 
> 2b.
> This changes two !NILP to CONSP to be consistent with the checks within
> read_char (see 3. below). This is fine under the assumption that the
> variables are always lists (as they should be). I was about to say that
> I can take this back if you feel it's too dangerous, but if this
> function needs to be split into two anyway, we won't need the change
> from !NILP to CONSP.
> 
> 3. "Fix -1 leaking from C to lisp in 'read-event' etc."
> 
> 3a.
> 
> On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> > And read_char is called in
> > several places, including by lread.c and read_char itself -- did you
> > figure out how will this change affect those?
> > 
> 
> Yes, I carefully checked all the callers. (I know, it's not trivial to
> review this commit, and I think any careful reviewer would need to do
> the same in the end...) The only caller which acts specially on -1 is
> read_key_sequence, so it makes sense to handle this case in
> read_key_sequence. This is done in this commit. The other callers are
> not prepared to get -1 (which is the root cause of the bug!), and
> exactly what we would like to avoid.
> 
> 3b.
> 
> On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> >   Moreover, the changes in read_char modify code more than is
> > necessary to handle the "at end of macro" situation, so we are
> > risking
> > changes that will break something else.  Here's an example:
> > 
> > > --- a/src/keyboard.c
> > > +++ b/src/keyboard.c
> > > @@ -2610,7 +2610,8 @@ read_char (int commandflag, Lisp_Object map,
> > >        goto reread_for_input_method;
> > >      }
> > >  
> > > -  if (!NILP (Vexecuting_kbd_macro))
> > > +  /* If we're executing a macro, process it unless we are at its
> > > end. */
> > > +  if (!NILP (Vexecuting_kbd_macro) && !at_end_of_macro_p ())
> > >      {
> > >        /* We set this to Qmacro; since that's not a frame, nobody
> > > will
> > >   try to switch frames on us, and the selected window will
> > > @@ -2624,15 +2625,6 @@ read_char (int commandflag, Lisp_Object map,
> > >   selected.  */
> > >        Vlast_event_frame = internal_last_event_frame = Qmacro;
> > >  
> > > -      /* Exit the macro if we are at the end.
> > > - Also, some things replace the macro with t
> > > - to force an early exit.  */
> > > -      if (at_end_of_macro_p ())
> > > - {
> > > -   XSETINT (c, -1);
> > > -   goto exit;
> > > - }
> > > -
> > 
> > This hunk moves the at_end_of_macro_p test to a higher level, which
> > has a side effect of not executing the code before the original
> > at_end_of_macro_p test -- how do we know this won't break something
> > that happens to depend on that code which will now not execute in the
> > at-end-of-macro case?
> 
> The commit takes care of this, and it's not too hard to verify: If you
> look at read_char, except for setting local variables, this is what it
> does above the original at_end_of_macro_p test:  
>  * if (CONSP (Vunread_post_input_method_events)) ...
>  * Vlast_event_device = Qnil;
>  * if (CONSP (Vunread_command_events)) ...
>  * if (CONSP (Vunread_input_method_events))
>  * Vlast_event_frame = internal_last_event_frame = Qmacro; (if in a kbd
>    macro)        
> 
> The "if" blocks don't matter. That's exactly why the caller checks for
> patch check for !requeued_events_pending_p () in the patch: if those
> blocks were to become active, we'd *not* skip read_char.
> 
> Consider "Vlast_event_frame = internal_last_event_frame = Qmacro". The
> purpose this is to indicate that the last event came from a kbd macro.
> Since we now don't return the "event" -1 any longer, it also doesn't
> make sense to set this in this case. (And when we read a new event,
> this will be correctly updated.)
> 
> What remains is setting "Vlast_event_device = Qnil". The same logic
> applies here. I don't think we should set to this nil at the end of a
> keyboard macro, because no new event was processed, i.e., the "last
> event" didn't change. That's why I choose to skip this line.
> 
> But it's certainly more conservative to keep the two assignments to
> avoid any unexpected consequences, I'm happy to add this to the caller
> with an appropriate comment, if this is desired
> 
> 4. "Remove workarounds for solved 'read-event' bug"
> 
> On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> > Also note that at least in subr.el we don't only test the -1 value,
> > we
> > also test that a keyboard macro is being executed, and in this and
> > other callers that handle -1, each application behaves in
> > application-specific way when it receives -1.  It is not clear to me
> > how your changes modify the behavior in those cases, and your
> > explanations and the log message doesn't seem to answer this
> > question.
> > For example, this code in calc-prog:
> > 
> > > --- a/lisp/calc/calc-prog.el
> > > +++ b/lisp/calc/calc-prog.el
> > > @@ -1230,8 +1230,6 @@ calc-kbd-skip-to-else-if
> > >   ch)
> > >      (while (>= count 0)
> > >        (setq ch (read-char))
> > > -      (if (= ch -1)
> > > -   (error "Unterminated Z[ in keyboard macro"))
> > >        (if (= ch ?Z)
> > >     (progn
> > >       (setq ch (read-char))
> > 
> > now signals a specific error in the case of an unterminated keyboard
> > macro: what will the behavior in that case be after the changes?
> 
> The behavior is that it will wait for interactive user input. Say you
> define a keyboard macro that performs only part of a calculation. Then
> instead of signaling an error, it will simply wait for the user the
> provide the remaining key strokes.
> 
> On Sat, 2024-01-06 at 10:15 +0100, Andreas Schwab wrote:
> > 
> > Seems like calc actually wants to know when the kbd macro ends
> > prematurely, and removing the option to detect it is a regression
> 
> To be honest, I really don't think that signaling an error here was a
> crucial feature. I'm pretty sure what happened is that -1 appeared as
> an unexpected return case, and then the error was added. Yes, this is a
> semantic change, but I think it's an acceptable one. This doesn't
> remove any real functionality, it simply avoids an error condition.
> 
> But one thing I wasn't sure about is whether the change that -1 can't
> occur anymore would warrant a NEWS item or similar. If yes, I'll add
> one. 
> 
> -------------
> 
> On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> > In this case, given
> > that we want a more elegant solution for a situation that we already
> > handle, I tend to avoid any such changes to begin with, for the
> > reasons I explained above, and instead perhaps document the special
> > meaning of -1 in these cases.  And if we want to consider such
> > changes
> > these dangers notwithstanding, I would like to see them affecting as
> > little other code as possible.  Can you suggest a safer changeset?
> 
> As I explained above, documenting this is not trivial either. While we
> can, of course, simply document that -1 can be returned, it's hard to
> give meaningful advice except "this function can return -1 and if it
> does and you really want to wait for input, set executing_kbd_macro to
> nil and try again", which is not only unelegant, but could have further
> consequences. 
> 
> I'm happy to make the changes based on your review and on other
> feedback, and expand the commit message a lot, and I think this will
> make the patches more conservative and safer. 
> 
> It's still not trivial to review and verify my analysis. But this is
> just how it is. The code change wasn't easy to come up with, so it's
> necessarily not very easy to review.
> 
> With the modifications I hinted at based on your review, I think what
> we end up with is:
> 1. commit: no semantic change
> 2. commit: will be reworked to have no semantic change at all
> 3. commit: only change is that -1 is not propagated to lisp, other
> callers of read_char are unaffected as I explained above. (modulo
> Vlast_event_device and Vlast_event_frame -- which I can also still set
> if you want me to to).
> 4. commit: this only removes code paths which are unreachable now, so
> again no semantic chance.
> 
> But then it will be good upfront if it's at least realistic that these
> patches get in in some form or another. If I can get conceptual
> approval or dismissal of this approach, I know what to do next.
> 
> Best,
> Tim
> 
> 




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#68272; Package emacs. Full text available.

Message received at 68272 <at> debbugs.gnu.org:


Received: (at 68272) by debbugs.gnu.org; 6 Jan 2024 14:32:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 06 09:32:43 2024
Received: from localhost ([127.0.0.1]:58858 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rM7j8-00061m-NH
	for submit <at> debbugs.gnu.org; Sat, 06 Jan 2024 09:32:43 -0500
Received: from mout-p-202.mailbox.org ([80.241.56.172]:48166)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <crypto@HIDDEN>) id 1rM7j5-00061W-1C
 for 68272 <at> debbugs.gnu.org; Sat, 06 Jan 2024 09:32:40 -0500
Received: from smtp202.mailbox.org (smtp202.mailbox.org
 [IPv6:2001:67c:2050:b231:465::202])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4T6jTP0L18z9sdD;
 Sat,  6 Jan 2024 15:32:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timruffing.de;
 s=MBO0001; t=1704551545;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
 bh=UgXpShXS8J8XI8wLkFCK8JaHCC8OYqP588v18ybpVJ0=;
 b=KH9Rp9ooI6DNO6Gqj41BeS2WpzrToPTciCSXvYgDODriXLtIc97EtBaoZSdOGmhOe7RRUm
 SVzwA1UyG2/CsBZh71be8xNykog5wvmcgHicRJKre3HUyon+pnzaUiNlWxC3bU2hPhvjqS
 yMny6kHNq+9TTUK8mN8e4JR8EJQlQ0pk1ePkhuHSGBuGuM2HZxId+alqQNo4nLgENTkGj4
 M8/HGZuTMVmIfcXXg+to1di2IEJdqW5E7o79WPgMs5a0E+K0GrewhZ7b2PED+Ewg1hO5Jr
 DFjc9DBBLEYzVoOZ171Mk/in4DWrAtJdpT8VTqZlA9ax43EBK0GSUqW1hZDVpQ==
Message-ID: <1b3fa12138838a3fe5643a9e76a65d32a677e34d.camel@HIDDEN>
Subject: Re: bug#68272: [PATCH] Fix -1 leaking from C to lisp in
 'read-event' etc.
From: Tim Ruffing <crypto@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Date: Sat, 06 Jan 2024 15:32:23 +0100
In-Reply-To: <83wmsmucuo.fsf@HIDDEN>
References: <46480759b6d89b5a4864e8ee1b986817366a56e5.camel@HIDDEN>
 <83wmsmucuo.fsf@HIDDEN>
Autocrypt: addr=crypto@HIDDEN; prefer-encrypt=mutual;
 keydata=mQINBFz4LCMBEADLgtVg3uT+kybmXDPpXMvd8KBhTfAL5DP6umC9hkv/WHnfbCOUujhyvBljckcExAFr7tDYSgIjqa0L32SCT0NEaeY/s3WOYIacjBIEjTrgt01401lOWoX3XeYTWOlVUmUg+4iJPmBSPaj2bJR9Sq6NZhQjQ8K24VMtUNMiDeIIcstLkvQ4ZWkSuBUQJrJ0gUCZcUHNEyyGyZj1HOVGqGK7hTIiT1TfAgYKDDzk955LzgxbmATJWQLD7AGUIjKf/s418PTxI7Hh5ptH+Rq30+wkfvzJumYgkWUzeV6jzlOST5LkrFWQTfCXNvFNxSI9FVKjDIJZ7nQlgd+qNpGop90S3UqA8ofoG9liJm/jmbgIfJTgIiJpulycJD90PyJiWxtGshuZnHjCpkmU5vc1ZbuYyzH2wLoABSBsjy3Tb/25W2mnYnsOcVo1sWOGl+08Lb63ocVYGY27OrAIsv35pS/gMSGcJVg/EmPIM4+PmjeOxDlrJEW+8YzjKV9XtDv6VcBT1/OcA64knWC7JAGf0CGRodpolDjyfFRLOPV2/UbyOMJZjkxKTtV0je/RiMTupIHWcmimkvzpNo8D8U+Ac7KTPuPBrbj8EWeTbd/sK6bncjPL2DLomov0gCg/qlgObYmZ834+tQcThIBi3cj1cRj/0yKPy1uHgk2P2jO5i9AXGQARAQABtB9UaW0gUnVmZmluZyA8dGltQHRpbXJ1ZmZpbmcuZGU+iQJXBBMBCABBAhsBBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAhkBFiEECeA/hxCS5A4QbpArM7yGq4D/VRYFAmVV0QQFCQo+2GEACgkQM7yGq4D/VRZuVg/7Bga2TnJPDsAz5bULJciAcsb63mvxIVge75ShidoSNjJgJcdpkRLQYmb2O3XnJoiCnHQ3Ut6VI6uhMgoFo/zDKGaYAIDIlUL70+Q7LPJTvDhiT9ugRy+p+gdBX
 3iA9duadpJ6KScMVl4zbzmc4wqq50nIGxBKMhYtxv89jINhMyR/zZN+AIyCC0BBnpvbtPH7x07v3PI6LryW+5ZqDVeJYMvBMecaDxcjXYSXU3489LmShH7IdqQs9Tq8OWVTAOoOAkNy9kMwkKSyXuYFmKwhPiSY3InPxfd6Na+kQLjWyHpRH+DQs287B0LaJGOKexNxd57SO1B5f1am4HPzTmKjZMFL1JQFrAyb+XZY9tbXT8Ncqmy2VKVl/pfDVrBOGMp72zji8vRlp7ZJDlZzCXm5RV2P+APCN41IBPkSVesLj9iLYTvyu4o1SUOLz1PpNJdqbuKIyoPzOYWOdfb5cObJnZxGFpMopwSxhP77lAFmUnusiVx/GvMjj33Ro2D/jiS911D0PJ75pFrUY1xF2FVsMQsI6x/iPVk2DXtOR6RF0a0ioijS7+JT6rgosTl8dowsB6co3TYODYDc1j9R4/mZOMzJF27D6nYWmthx7zqg+VK4jm1k/IZIET0IIrHYoEzvDfnpDCKDc6D9cXFr2bGvYYxRBd2ZFciFjcBsXIpkEEa0IlRpbSBSdWZmaW5nIDxjcnlwdG9AdGltcnVmZmluZy5kZT6JAlQEEwEIAD4CGwEFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQQJ4D+HEJLkDhBukCszvIargP9VFgUCZVXRCAUJCj7YYQAKCRAzvIargP9VFt0OD/4/fGJ/pF4/CeXl0EfnruSxTjJi/60q5/CYmEbvFfG8eMyiOGlemVr021Gfzl1v5LMCDPa4NWb5bJA3tae88LPv2UO7+uD/z04gA52ZQm6nlkJhDrLacwKU+x4E0RsPf8lonF2FlKhOCbUaqlDwfoPjGVauhEBGfU6bUGQI1gzHEk9rzI6GsTCVo8Pc+RtqBOb73tdgOkj5gYqpTS/hKJd8lKp2DAQravMnK0sSLHw1fTXYW1+bcXi4GLd+Uw/ZjSxK8Rf0einckdOpS9
 7iuzPQ/MQ3163JDuUemQO0pseMfmvUgadCHT9PKs84cDukB7v7dYG6lAnBJtUONR3mOZn5lyLU2lv+5gE3pGr9tz1PY7by5/w+ttuYQdznoUz4sn+rSwAZQO6xoSJI9xCajtxjsHFEKcSOFNgiAIjJGXcZp3kdh1JPJ0iIv2fsqYo7TAxLLA2+86PQIwLe0nckog9pPTzKVar/pMlKf5/4926dwmGSBW1cwyfC8rY3qyOhao4gpA/EwxQnmWs1/+b0QQdiY4ktv80C5cMvk2LetzFELx+MMfeIXkPgriqXSsxK8gLNZqsYl9z96w+1tmXikKBS7GuJf+FJAdcQxw1gdLMp8t8FTFMN3QC5bot3jYOgC21n0CUxCTgbYv0ymKTojYdB06CVfu5YJoYqR0r5wUwQcLQiVGltIFJ1ZmZpbmcgPHB1YmxpY0B0aW1ydWZmaW5nLmRlPokCVAQTAQgAPgIbAQULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBAngP4cQkuQOEG6QKzO8hquA/1UWBQJlVdEIBQkKPthhAAoJEDO8hquA/1UWSoUQAIsiyIf7fqvwdGpkHAzkAbFipLfzcyp8su415ySdTrQTW29sTsyPIjN6r0RW0HSJWtPH43qgUgjRs+3fF0Obsdf9heNAY6KZmdyJ91rzbIWYOOGEAs4kqDwVMt5gBXz6N1eXYBVitjBaDRPCgq3sHUa3q5Vpo162UKgatIameThBrGgUFQhpUhbYKtp5161KRg2J4Iaz6sdcun31y27OMQdeT9o03RbQqmc6BXND/3h+aufOHDQov6vo87FrG4Qi86SRg5vQGOy0VPzU54X2Kf48oKiqBDKFcBaDljgryOL9e8i/Qmusr/YHwVZKwVerTxwGbftHIc7unlLTi4Ke6+XcseLd6SY7Cl6X2npuExaVd2fZ6UVa3qHoUf9uhN23JLLJHc5Pyf4evQ7J1Rulvz7BJPu8ctwNFBOBzfX
 6PhWm78OkNqMS8axCQ75HOz5xNJ24aGOumej+CyVvnop/aosjnRTfYWm8Xfjo7wu4uEF4XdeVPKp1XUY9nxWXksxvyXapYhVWdU3PlpJPD8ION28/QjPZtwNdKVmRtTrwd7hUDgJFr9GXGfsE+mQx84myde7n8AV5IOgTn45JYlCF8jay3lk+7cSqh6zHpbBdUPG9BFNACdLZUGmlZ0lj1QtLwXVr0Tm+5jvVlbYYbJJfoKUY7Ch8AvEf2FCBYmn0fb12uQINBFz4L28BEADdPI1M2yQTI/j1kyEkfOfvD22/DaHCmnFUkfYY7/2rij0QvWD11WL6ZSW9KcwPkufWBxftMyNlftIs3x177M7IyTNpzx3RKhL+iNgSeAilOxVZEq0aP5Y94T4h+w5Ck1vRKhceH97Yz7ubp2/07mD5tcb1n3EOg2Po412jjrE58PxXvQf14QMHLDLjiB9zcUjGYNQ+9EKQ4NU4kBqHtRByL4UfqtlHZTIDcjGBXFRCmztGVo9BoT6RydtIp67SQe06v5AFuFQeuBOv5AqObLCvL5tTo20AfQPm1f+H7tOecmdSPLbWR4Gs7KFBq3R3BUFIt90nq5h4iSygCbsXqYcQgcqR3AmtaJyrBX9OEFrRb+0DJEUgMt+ndAoY8l2VmtlHgKV4TovvRonhgCuEtxorJC0OUstrIHP47ilxnMEwJhd2oS3Hly7gw0Rsu9Xkgkge1NIGFLQvljeRmqsAYYrJkpBnaxcUXvQ4nBPJj5pdQhmFy+0q1IaTEWUqNI2JuPvt3MydXUqDZxGDd+IUA0GrBhV0R0zw16nNAsmH/OmtQLPVpUOuu8tOK7Z3E6P5m3FXIwnXH6piWpDfeqQmt/IJGKoQ6CLFTI4AgFbsRpTyN1RKK4HhytYPLIJPnWNnfF8e07T1Hv83LqMctjl/6RbmzGwRstMANFYKjRdUzdujOQARAQABiQI8BBgBCAAmAhsMFiEECeA/hxCS5A4Q
 bpArM7yGq4D/VRYFAmVV0RYFCQlK76cACgkQM7yGq4D/VRZmyBAAsJHjdiZqG7C+V5I2/sthUflMock6Se5xJ+bzhGoP7VwhdUcRNnKWUkZaj+jt4f3zckoPIB/RmVSfNXxzp9S0wJGpsqpudYUP97I4fkmyYxTiZFxYUVLv3vuYC4XF2PeSMg3jRKYQ2Zck+uju+TyUdQc2jpIgl/p87f/koxbhD2PkRn1gSU+PxqfVlNqxamrJaLNs7qwUOA4GTciy2IhWvFhvUSV/CXxhpvVFM+fFQD/dY5iP/LnzhqNMrHPj4VLdZMSZIdGyWdYUVP6MLU3WZ/Db5j37wdV93jNFi3wdSO/7jJZ29pGcX2b8W0nXsmfoL1SnRPVDAeI9VT1XF4kDWelDe6gJPVO1MiygSAGQ2sYsQq5LonQAgklAyXQ8P80HNdHTYBp4pR8lucSTcxGqALDXOdnuxPpEgFpy3tP78L7L/2AMZ5B2bYusBXeboGsLlsdTdNSN4cPRHyxR9u70b4sp1NsfwteeTEnUt6PLgwEEpaUn7LYltq1ejpWupRe15XnmehmDB5V8CxoLkpPEME4hr8F+3YxPLD68O591M1sc7Lc28X9O4EjBfx9lTstsezkB+F6mAKHlcp9fAbAG1dL84BBwXSn+ZR75YP5yNWcltFktWJ2YBsi7Vl1B/C2/OPPMxKoqlzoFiosucyNCMkQtgij0Tul4fFTeZ/DCda65Ag0EXPgvnQEQALnSCArYa7E9XRTSfxV+d5QyhZD11vRVgkH4OJfRTY+prjgmcB1+mIRZ4l3syiq81KeQGSmW0a2Ce8o0aF59DkgnFo1TMtGDzX/eZyxe/Fwuk7yNKAqR6MVLf/bnGSjhbBr4NefpWbHks2dkGBUbfzi0EocvxbwLZpLpumgtDLFKiot8VSj0hmmcz2uG9tAIKmM7rcXOMJbsNxI2fDPd0KoB61jOxkcT+AMtYIqxwd5ej8mWL5LsGDATz
 RZCIkOSUnHPeGrsYLR7ILqfFfSMdnXINu9UhuLSupmYVtm5g0zgFDn1u7XuJBp2epapfQ3EsQAYDFLRg1thJBT7h2Z4yyvWiGUiL07dyvpDDatkPUz8WgEBY0Fsnubpvfw9mslpPLabsARDJM76TvSNibcPxIeGgfr8GPV6qUNtWkqt0xrh90Di5IRb1u8kRxDt+aIir4Yq2J+2Ew/dtBs11HoDu84OC+8ck2gL0+TE9/dPm4yOF7eaKn7kkj+yT4I+aJtyhM2lQNME4vK8XJpgq3JPShlZPbYK/lLcHpFEBOrsDAJNwpc7iJYWJn6j3/Fiy5mKA68wIqbkOde+ZhgZXS51l94vLMM7tyhyDPd+4kSdzcLBcCc0lIzXDUe7cmXvjC/NwvjkoPuabM9H9VvhRea4t9Lc9hxSAaFoXZbq4omNOaoPABEBAAGJBHIEGAEIACYCGwIWIQQJ4D+HEJLkDhBukCszvIargP9VFgUCZVXRFgUJCUrveQJAwXQgBBkBCAAdFiEEAWT4Ukhg5KuhCfYse5ruiDUJqtgFAlz4L50ACgkQe5ruiDUJqthCwA/9GGMgxtD8hlel72mU7VVN79mzCmRTqpV4INR+kKX+kGW28rBTSxq1Cp2spaC1gbLNKFuiLQVjZ6la3CBfww6uRtUctU7k5edqiYgczsezNagNBOxP4EcVaK4ZWnRFdSceQck2ZCfSnYqI2k1FkcxOvBvRuMfxFaeeJ2VBo/+4vlGGjdvlr98Ewv1WgQv3ncvYDAbswM2KbD9wiZU1RMYvmpPCGzLE+mol2O3jWWDg7lrjdE0NOSSArBoYGi0qMYqA230IXmNWnc1l1LZLW9TETb94w+XaWHVgK7goKgNI+cQlzrZZ4cRSZx3x0Ws8gXXcMTqJ61+UjSUwfe3tIq5Nnt1juv3uaVL6GgxsrrLnHDf8BUi/dvprMuORbnCPfxDkwDe/GsZAxkk7JH1xtW0hU69bxtzQ7TlZKF
 t5GL+4vJMBlmODWZncrSzvLpr+itt3VfO4bNlMXadQ0nCn4gWHfH2RYUCKAavg0oqgcmS2KGSXaRvUd/2SCS29BC5OmRvCcPwrkwZE9iVX4zEgUk3l/8TKXronjwPHy8g/LGzLXb+qmYea1Dwt9wsyZmsniMA+ixBSN7nolflJ9hFIZzj2eTXj1WHK9Ye/xS3TktKFJ7nvg5C5TQxOkXRrZ8eXt4Ho6rQWoJtjThlQEdYygR/SG9OenDzkZu7qeCx+HEEyjGsJEDO8hquA/1UWPQgP/187VkxMx0WZazyekn4P/cXAKu2ox5RCzZaey1u79nYsbGDrBwwWQvLz9Gf97+nWeCU2RLqlM2oIIsiyAANOMevclBvAWygboFcfy1US6DMCj+b+ottsqujt+tx3nhTjvod4nyUkbnQGJgXV6q9WQK9c52J2VjexiR5RMqhhVybGDpttgu/8gu7vTQwF7jDi1FEm3xGsp069NNkoN4dcsHkpebgm1Bmzw9ULM5L6VLSqZpgj9mXGpfVFPLDXRbVoQFh2WtiF7RZIU20S6Vkmgvawn5DfE600W1CcgC/CxQX/SfBrLI5tAYqbAaQZrcWaOxqG1/PAFDxwCZQgxX4cw7LBPDpTHW+OUqL1yhRyWL5TSfxf+aXTO5lFPZaW82gyDL+sJhTTknnG7Zh+RZtDP7rhqR2YI7LNn9mG7XHnKai7Lr3IQ0lBeIh98dqCpCDawNARlKIamdWK5owCKCm2wsZAcpxEzEFFArHVklo1TXsnW3Ywoyb4c7TMdFjUhLhdcv+SIIUtUFHKoAlIkG0u15Fv5ZC7nLtwTrDuJW8hmQRw2k2y4TSbohWgDCV2/KSH1I/PflU+cze8WQeRQqmde2fWxSgPTA7ugSyBPkpGNdYQBFnuqfxezZDSTVzyh3DNpqsxGt8E560mC/KA+YNAAjGF0ePw7/Rh9sPXLFv88wFWuDMEXQT37RYJKwYBBAHaRw8BAQdAHPP
 jBVFc2oReNQB1+0rKKMjRCq6cU5jEl9jx+JlCvUKJArMEGAEIACYCGwIWIQQJ4D+HEJLkDhBukCszvIargP9VFgUCZVXRFgUJCT4nKQCBdiAEGRYIAB0WIQQABqSRH1VT5c4FNCGMRhzNKT9gEQUCXQT37QAKCRCMRhzNKT9gEYK1AP9g+AkebpYEqtNtHOyAuQJF/aTCNOXdPSBOtR5/y7iNVAEAl4aEB2Ofue9yjBBGOgRA65sGMxgEmI9PCU7kitqyoA8JEDO8hquA/1UWqm0QALM+y3hODe5/X7eSPHd36r2vaVXUKR3CPxr0yAZvcf3vKubyBagZKtFB49fYi8xZTe4iMd3Ozh8sHezWdb8f0/IMidmr+CD/NZg9OjFMNI+n/nmC1Qugdxq9ZbhohqftDEJirf3AMau/LVojjwsDi26r+/5nA3C9Iw4KVJqC3F/M1wq+fTJmj4Hd0tDHPapOtdfkposver/BzhnQ2fxKwejc0pI81ea2bBIoLcdC+aJ51W/GhzA0grWz8ssczP1JYgJIAlrthMYnTfGht6fLvD7hwr6vGoeI5V2yqci9dKdu5hTuWjWxNZBK12qMx+YN1s1mythxfRkHk2tOZ0am5BSSUw7Yn43TXlN9wc5pmguRhe3e7yC6tiHVJvl6pMP2lO8Ddmeqsf3C8WJwKYGzgnDGOQHcDZuSvFnRmS45D1DJ2MrDCepa9gSeFX/pbGsYuJrJklOMhMXffpgWlgwNWEaejxaLmhLt654NqFkBLo+aQTUkctH1Sf2FTCQOGBKfJXIZC8IzES7PT0r2E7UW+tJONb3dWenRKdBKppxqDVziLlfloEwRz1qGb/ZE1iQ/DHxa2IBkYLwDo0u7wzadA6AESNHJMcPHPPvEE7h0QJ/Pcl/MKjoI2LM3PKS1HE9nlnBN2lnfc6ZRMJapoA5cU0XbPsR7EAflLmYXKiJ+cIj4uE8EXPgwtBMFK4EEAAoCAwQwnnl1+/Yq
 AabnWn5xW3ux6PQE42O3KSDnFrSeROYQsnhY5DNAW3Zx+xRKBCHLvru785zMDsEmjpybZsb+i6OqiQKzBBgBCAAmAhsCFiEECeA/hxCS5A4QbpArM7yGq4D/VRYFAmVV0RYFCQlK7mIAgXYgBBkTCAAdFiEEtGU/qLvs74ko5Fi+s+HYaWSq3AwFAlz4MLQACgkQs+HYaWSq3AwVZAEAsFAzHbeIuSRb/D4+2hQL2m1HtnrDzKuI8zFT2Ryd0EgBAOcziZTKy+VIH3woL+EghEvjH3DPdTARuzYmgHbZMOqwCRAzvIargP9VFhefD/9RTbKteoaeYCJE0yn3KEa9J847C/nx/N6bPGomHslOEbhmIMknvfEwgppbRmnMhf3HeGaxsnpCDYNk4qrzrSrj7YtS5e4rCozjswJbA/MySx032Lm6fj6pAqe+yUbvOaKlyfcOQm0Rd7kTHjlCabnQWe1dDw3ihVnhpBwfjEYcQnttlhrGPUvdYI38dN9wSJTxme3EF9ZQJ9V74xJMTbS/GYTymabzQOcAk9VwzKyxBWR/x5wp1EDPMdBccMgYUKls7shCX0Kie1WqyjOIUqGVqRHecQPpnuXM+VLI/bqMUUfgMQbGHYFJJCgaLWkvTVKyLH7vdTeVDpgd6m+1voi2NXBtg9mgUx4XIItT8PbbveMxOrRwh2WDPX+lYLjXsG7IUCfdlSWEyZWMbljfNhPUrOtBm/blWHOrbGWrvGfkMWZZGD6dLAHSsQdoprp6OOT9gpEv5lQ7AKyl3jEPkHSsMDylHACi0Hd/xgKbrT9ir7ZKibUgCDcO3D9W+QMD0efKoWuPAY7vEQd8+mxIqH8BEcTiInsj4nu/xcw3eVWoFuQf3k85vF5O7qBbEX0fhwDGBTXEd7g5e87kXKV4KBZRLO4QpaRcvpJs7fBR3uxsbuE5cR5LugSkkSHJdZI2KossVMIbW5AoPw8Ov2/zrXStrJxS8eGs/Su6k1zh6
 7xWBA==
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Rspamd-Queue-Id: 4T6jTP0L18z9sdD
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 68272
Cc: 68272 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hey, thank you very much for the long email. I was somewhat prepared
for hesitant reply, and I totally understand that "there be dragons".
And I'm also aware that it doesn't spark confidence when someone with
(almost) zero code contributions submits a patch of this kind. I feel
the same when new people send complex patches to the C library I
maintain... And sure, it took a me quite a while to navigate this maze
of keyboard.c and to come up with this patch and make the tests pass,
but I feel rather confident now that this is the right approach.

I agree, we can never be fully sure that this introduces regressions,
but let me still try to convince you that this approach and these
patches are carefully crafted and thought through. Here's my analysis
of the situation:

First of all, I think the bug is real. read-event (and read-char and
read-char-exclusive, which I won't mention from now on for brevity) can
return -1, but the docs don't mention -1, and it's arguably a strange
"magic" value for a lisp function. If anything, one would expect nil,
or some special symbol. Of course, we could simply document the -1
return value.=C2=A0

But the problem is not just that this is not elegant. It's worse
because it's also pretty unclear what the caller should do in this
case. In particular, the caller can't simply skip the -1 and try again:
The caller will see an infinite stream of -1 values, until the keyboard
macro has been resolved properly, i.e., as long as executing_kbd_macro
is non-nil. One thing the caller can simply do is to error out. But if
the caller wants an event, the only thing it can do is to touch
executing_kbd_macro and set it nil explicitly (this is what subr.el
does currently). We could also document this, but I feel something like
"this function can return -1 and if it does, set executing_kbd_macro to
nil and try again" is really a bit too unelegant (and it has more
downsides, see next paragraph).

However, this now hints at a different approach: Could we handle this
in read-event locally and just perform the retrying for the caller?
First of all, we'd probably still do it one level below in the call
stack in order not to mess up with the timeouts (if we simply try
again, we could double the timeout), so we'd want to do it
inread_filtered_event. But I think that approach will then be *not*
localized and thus dangerous: it's not clear if setting
executing_kbd_macro to nil has unexpected side effects have. Resolving
the macro properly is ultimately the responsibility of
Fexecute_kbd_macro and pop_kbd_macro in macros.c, and we shouldn't just
declare at some other point in the code that we wish the macro handling
to be done.

-------------

Let me try to convince you that these commits are more harmless than
they look at the first glance. I'll go through them one by one. I'm
also happy to add a revised version of this to the commit messages.

1. "Extract check for end of macro to function":
This is pure refactoring. A brief code review shows that this does not
change semantics at all.

2. "src/keyboard.c (requeued_events_pending_p): Revive"

2a.

On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> =C2=A0 For example, your patches modify
> requeued_events_pending_p, but that function is called in several
> places, including outside of keyboard.c -- how can we be sure we are
> not introducing regressions this way?=C2=A0

Oh, good catch. In fact, it's (without the patches here) only called
outside of keyboard.c. I was misled by the comment that said "This
isn't used yet. The hope is to make wait_reading_process_output call
it". Indeed, this comment is outdated and the (only) caller is
wait_reading_process_output. wait_reading_process_output really wants
only keyboard output, so it should really just=C2=A0check
Vunread_command_events and not unread_post_input_method_events and
Vunread_input_method_events; the latter two are for non-keyboard input.
I can rework this. I think the way to go is to split this into two
functions requeued_events_pending_p and
requeued_command_events_pending_p or similar, and fix the outdated
comment.

2b.
This changes two !NILP to CONSP to be consistent with the checks within
read_char (see 3. below). This is fine under the assumption that the
variables are always lists (as they should be). I was about to say that
I can take this back if you feel it's too dangerous, but if this
function needs to be split into two anyway, we won't need the change
from !NILP to CONSP.

3. "Fix -1 leaking from C to lisp in 'read-event' etc."

3a.

On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> And read_char is called in
> several places, including by lread.c and read_char itself -- did you
> figure out how will this change affect those?
>=20

Yes, I carefully checked all the callers. (I know, it's not trivial to
review this commit, and I think any careful reviewer would need to do
the same in the end...) The only caller which acts specially on -1 is
read_key_sequence, so it makes sense to handle this case in
read_key_sequence. This is done in this commit. The other callers are
not prepared to get -1 (which is the root cause of the bug!), and
exactly what we would like to avoid.

3b.

On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> =C2=A0 Moreover, the changes in read_char modify code more than is
> necessary to handle the "at end of macro" situation, so we are
> risking
> changes that will break something else.=C2=A0 Here's an example:
>=20
> > --- a/src/keyboard.c
> > +++ b/src/keyboard.c
> > @@ -2610,7 +2610,8 @@ read_char (int commandflag, Lisp_Object map,
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto reread_for_input_method;
> > =C2=A0=C2=A0=C2=A0=C2=A0 }
> > =C2=A0
> > -=C2=A0 if (!NILP (Vexecuting_kbd_macro))
> > +=C2=A0 /* If we're executing a macro, process it unless we are at its
> > end. */
> > +=C2=A0 if (!NILP (Vexecuting_kbd_macro) && !at_end_of_macro_p ())
> > =C2=A0=C2=A0=C2=A0=C2=A0 {
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* We set this to Qmacro; since th=
at's not a frame, nobody
> > will
> > =C2=A0 try to switch frames on us, and the selected window will
> > @@ -2624,15 +2625,6 @@ read_char (int commandflag, Lisp_Object map,
> > =C2=A0 selected.=C2=A0 */
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Vlast_event_frame =3D internal_las=
t_event_frame =3D Qmacro;
> > =C2=A0
> > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* Exit the macro if we are at the end.
> > - Also, some things replace the macro with t
> > - to force an early exit.=C2=A0 */
> > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (at_end_of_macro_p ())
> > - {
> > - =C2=A0 XSETINT (c, -1);
> > - =C2=A0 goto exit;
> > - }
> > -
>=20
> This hunk moves the at_end_of_macro_p test to a higher level, which
> has a side effect of not executing the code before the original
> at_end_of_macro_p test -- how do we know this won't break something
> that happens to depend on that code which will now not execute in the
> at-end-of-macro case?

The commit takes care of this, and it's not too hard to verify: If you
look at read_char, except for setting local variables, this is what it
does above the original at_end_of_macro_p test: =C2=A0
 * if (CONSP (Vunread_post_input_method_events)) ...
 * Vlast_event_device =3D Qnil;
 * if (CONSP (Vunread_command_events)) ...
 * if (CONSP (Vunread_input_method_events))
 * Vlast_event_frame =3D internal_last_event_frame =3D Qmacro; (if in a kbd
   macro) =C2=A0 =C2=A0 =C2=A0 =C2=A0

The "if" blocks don't matter. That's exactly why the caller checks for
patch check for !requeued_events_pending_p () in the patch: if those
blocks were to become active, we'd *not* skip read_char.

Consider "Vlast_event_frame =3D internal_last_event_frame =3D Qmacro". The
purpose this is to indicate that the last event came from a kbd macro.
Since we now don't return the "event" -1 any longer, it also doesn't
make sense to set this in this case.=C2=A0(And when we read a new event,
this will be correctly updated.)

What remains is setting "Vlast_event_device =3D Qnil". The same logic
applies here. I don't think we should set to this nil at the end of a
keyboard macro, because no new event was processed, i.e., the "last
event" didn't change. That's why I choose to skip this line.

But it's certainly more conservative to keep the two assignments to
avoid any unexpected consequences, I'm happy to add this to the caller
with an appropriate comment, if this is desired

4. "Remove workarounds for solved 'read-event' bug"

On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> Also note that at least in subr.el we don't only test the -1 value,
> we
> also test that a keyboard macro is being executed, and in this and
> other callers that handle -1, each application behaves in
> application-specific way when it receives -1.=C2=A0 It is not clear to me
> how your changes modify the behavior in those cases, and your
> explanations and the log message doesn't seem to answer this
> question.
> For example, this code in calc-prog:
>=20
> > --- a/lisp/calc/calc-prog.el
> > +++ b/lisp/calc/calc-prog.el
> > @@ -1230,8 +1230,6 @@ calc-kbd-skip-to-else-if
> > =C2=A0 ch)
> > =C2=A0=C2=A0=C2=A0=C2=A0 (while (>=3D count 0)
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (setq ch (read-char))
> > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (if (=3D ch -1)
> > - =C2=A0 (error "Unterminated Z[ in keyboard macro"))
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (if (=3D ch ?Z)
> > =C2=A0 =C2=A0 (progn
> > =C2=A0 =C2=A0=C2=A0=C2=A0 (setq ch (read-char))
>=20
> now signals a specific error in the case of an unterminated keyboard
> macro: what will the behavior in that case be after the changes?

The behavior is that it will wait for interactive user input. Say you
define a keyboard macro that performs only part of a calculation. Then
instead of signaling an error, it will simply wait for the user the
provide the remaining key strokes.

On Sat, 2024-01-06 at 10:15 +0100, Andreas Schwab wrote:
>=20
> Seems like calc actually wants to know when the kbd macro ends
> prematurely, and removing the option to detect it is a regression

To be honest, I really don't think that signaling an error here was a
crucial feature. I'm pretty sure what happened is that -1 appeared as
an unexpected return case, and then the error was added. Yes, this is a
semantic change, but I think it's an acceptable one. This doesn't
remove any real functionality, it simply avoids an error condition.

But one thing I wasn't sure about is whether the change that -1 can't
occur anymore would warrant a NEWS item or similar. If yes, I'll add
one.=20

-------------

On Sat, 2024-01-06 at 09:42 +0200, Eli Zaretskii wrote:
> In this case, given
> that we want a more elegant solution for a situation that we already
> handle, I tend to avoid any such changes to begin with, for the
> reasons I explained above, and instead perhaps document the special
> meaning of -1 in these cases.=C2=A0 And if we want to consider such
> changes
> these dangers notwithstanding, I would like to see them affecting as
> little other code as possible.=C2=A0 Can you suggest a safer changeset?

As I explained above, documenting this is not trivial either. While we
can, of course, simply document that -1 can be returned, it's hard to
give meaningful advice except "this function can return -1 and if it
does and you really want to wait for input, set executing_kbd_macro to
nil and try again", which is not only unelegant, but could have further
consequences.=20

I'm happy to make the changes based on your review and on other
feedback, and expand the commit message a lot, and I think this will
make the patches more conservative and safer.=C2=A0

It's still not trivial to review and verify my analysis. But this is
just how it is. The code change wasn't easy to come up with, so it's
necessarily not very easy to review.

With the modifications I hinted at based on your review, I think what
we end up with is:
1. commit: no semantic change
2. commit: will be reworked to have no semantic change at all
3. commit: only change is that -1 is not propagated to lisp, other
callers of read_char are unaffected as I explained above. (modulo
Vlast_event_device and Vlast_event_frame -- which I can also still set
if you want me to to).
4. commit: this only removes code paths which are unreachable now, so
again no semantic chance.

But then it will be good upfront if it's at least realistic that these
patches get in in some form or another. If I can get conceptual
approval or dismissal of this approach, I know what to do next.

Best,
Tim





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#68272; Package emacs. Full text available.

Message received at 68272 <at> debbugs.gnu.org:


Received: (at 68272) by debbugs.gnu.org; 6 Jan 2024 09:15:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 06 04:15:37 2024
Received: from localhost ([127.0.0.1]:58578 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rM2mH-0000W7-Cy
	for submit <at> debbugs.gnu.org; Sat, 06 Jan 2024 04:15:37 -0500
Received: from mail-out.m-online.net ([212.18.0.9]:56011)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <whitebox@HIDDEN>) id 1rM2mE-0000NH-FQ
 for 68272 <at> debbugs.gnu.org; Sat, 06 Jan 2024 04:15:36 -0500
Received: from frontend01.mail.m-online.net (unknown [192.168.8.182])
 by mail-out.m-online.net (Postfix) with ESMTP id 4T6ZRg2hLdz1qsP5;
 Sat,  6 Jan 2024 10:15:27 +0100 (CET)
Received: from localhost (dynscan1.mnet-online.de [192.168.6.68])
 by mail.m-online.net (Postfix) with ESMTP id 4T6ZRg1Rwjz1qqlS;
 Sat,  6 Jan 2024 10:15:27 +0100 (CET)
X-Virus-Scanned: amavis at mnet-online.de
Received: from mail.mnet-online.de ([192.168.8.182])
 by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024)
 with ESMTP id Hct6Wpj4GXAW; Sat,  6 Jan 2024 10:15:26 +0100 (CET)
X-Auth-Info: wSDLGfb5kpzh1/cUjNIFVO9a4e9qwh91p/68mDN98Rl1JfO0cM01VHT7dpMDGo6w
Received: from tiger.home (aftr-62-216-202-146.dynamic.mnet-online.de
 [62.216.202.146])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mail.mnet-online.de (Postfix) with ESMTPSA;
 Sat,  6 Jan 2024 10:15:26 +0100 (CET)
Received: by tiger.home (Postfix, from userid 1000)
 id 28F192455C3; Sat,  6 Jan 2024 10:15:26 +0100 (CET)
From: Andreas Schwab <schwab@HIDDEN>
To: Tim Ruffing <crypto@HIDDEN>
Subject: Re: bug#68272: [PATCH] Fix -1 leaking from C to lisp in
 'read-event' etc.
In-Reply-To: <46480759b6d89b5a4864e8ee1b986817366a56e5.camel@HIDDEN>
 (Tim Ruffing's message of "Fri, 05 Jan 2024 22:19:10 +0100")
References: <46480759b6d89b5a4864e8ee1b986817366a56e5.camel@HIDDEN>
X-Yow: What I want to find out is -- do parrots know much about Astro-Turf?
Date: Sat, 06 Jan 2024 10:15:26 +0100
Message-ID: <87cyueg6vl.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.5 (/)
X-Debbugs-Envelope-To: 68272
Cc: 68272 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.5 (-)

On Jan 05 2024, Tim Ruffing wrote:

> From e73e08927792303013a8a9935656365f9f2299b6 Mon Sep 17 00:00:00 2001
> From: Tim Ruffing <crypto@HIDDEN>
> Date: Wed, 27 Dec 2023 14:32:09 +0100
> Subject: [PATCH 4/4] Remove workarounds for solved 'read-event' bug
>
> * lisp/subr.el (read-char-choice-with-read-key):
> * lisp/net/dbus.el (dbus-call-method):
> * lisp/calc/calc-prog.el:
> Remove workarounds for the bug fixed in the previous commit
> ac82baea1c41ec974ad49f2861ae6c06bda2b4ed, where 'read-event',
> 'read-char' and 'read-char-exclusively' could return wrongly -1.
> In the case of lisp/dbus.el, this reverts commit
> 7177393826c73c87ffe9b428f0e5edae244d7a98.
> ---
>  lisp/calc/calc-prog.el | 6 ------
>  lisp/net/dbus.el       | 6 +-----
>  lisp/subr.el           | 5 -----
>  3 files changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/lisp/calc/calc-prog.el b/lisp/calc/calc-prog.el
> index 03210995eb3..177c179433d 100644
> --- a/lisp/calc/calc-prog.el
> +++ b/lisp/calc/calc-prog.el
> @@ -1230,8 +1230,6 @@ calc-kbd-skip-to-else-if
>  	ch)
>      (while (>= count 0)
>        (setq ch (read-char))
> -      (if (= ch -1)
> -	  (error "Unterminated Z[ in keyboard macro"))

Seems like calc actually wants to know when the kbd macro ends
prematurely, and removing the option to detect it is a regression.

-- 
Andreas Schwab, schwab@HIDDEN
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#68272; Package emacs. Full text available.

Message received at 68272 <at> debbugs.gnu.org:


Received: (at 68272) by debbugs.gnu.org; 6 Jan 2024 07:43:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 06 02:43:08 2024
Received: from localhost ([127.0.0.1]:58489 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rM1Kl-0006Qd-Mj
	for submit <at> debbugs.gnu.org; Sat, 06 Jan 2024 02:43:08 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:42184)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1rM1Kf-0006Q5-WA
 for 68272 <at> debbugs.gnu.org; Sat, 06 Jan 2024 02:43:06 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1rM1KV-00014C-1l; Sat, 06 Jan 2024 02:42:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=Bmd7W9he294eibqJoBh5BmxpYXKRUGUSMF66jhhaEa4=; b=JniZypxfQqlXlxTTomW2
 8M6DycCrW0bbrDzT3h56yUk2lQ4+oiusoX5OrmIGYgJxa3ITs49ekOtYXaFGP1nf9O32AoKFXOlQJ
 62Gr7kQ6652nJJdog0EZ0WLoC9sou/yeCBQ/9/uJ1FgQa+s+27D3t6pNE8t1meYE8rG0Gd2nQkQt7
 q6988bSjbtpyWRAJNdV0PLr01l2xU1uF4G2vdiVhLidpJlWSEYJnm54cBO/DZYdwqKzMCcrq6QLMN
 2sSR+ZM7kOAG2s54FFm9c8PvOQgLtf9I2orL9ci9Ez50M9bS/HM20gRX0CxtrpJRj0lTqyeYcIvmU
 O6pGzW6Q2ZkDIg==;
Date: Sat, 06 Jan 2024 09:42:39 +0200
Message-Id: <83wmsmucuo.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Tim Ruffing <crypto@HIDDEN>
In-Reply-To: <46480759b6d89b5a4864e8ee1b986817366a56e5.camel@HIDDEN>
 (message from Tim Ruffing on Fri, 05 Jan 2024 22:19:10 +0100)
Subject: Re: bug#68272: [PATCH] Fix -1 leaking from C to lisp in 'read-event'
 etc.
References: <46480759b6d89b5a4864e8ee1b986817366a56e5.camel@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 68272
Cc: 68272 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Tim Ruffing <crypto@HIDDEN>
> Date: Fri, 05 Jan 2024 22:19:10 +0100
> 
> 'read_char' in src/keyboard.c returns -1 to indicate the end of a
> keyboard macro. This case is supposed to be propagated via 
> 'read_key_sequence' and 'command_loop_2' to 'Fexecute_kbd_macro'.
> 
> But 'read_key_sequence' is not the only caller of 'read_char'. It is
> also called by 'read-event' and similar lisp functions, and in that
> case, the magic C return value -1 is wrongly propagated to the lisp
> caller. 
> 
> There are at least workarounds for this bug in at least three lisp
> modules in the code base, in subr.el, in calc and most recently added
> in dbus.el (bug #62018), see the attached patches. These patches are
> supposed to resolve the underlying issue, and then remove the
> workarounds.

"There be dragons."  AFAIU, this is basically a cleanup: a non-elegant
solution already exists, but we'd want to do it more elegantly.  In
such cases, and in a maze such as keyboard.c's processing of input and
related code, the danger is to introduce regressions because some code
somewhere expects something to happen, and the changes disrupt that.
With that in mind, couldn't we solve this in a more localized manner,
such that we are sure the changes could not affect unrelated code
paths and use cases?  For example, your patches modify
requeued_events_pending_p, but that function is called in several
places, including outside of keyboard.c -- how can we be sure we are
not introducing regressions this way?  And read_char is called in
several places, including by lread.c and read_char itself -- did you
figure out how will this change affect those?

Given your description above, that read_char is called by read-event
and other Lisp functions, I would expect a fix to be localized to
read_char and those functions calling read_char (to limit special
handling of -1 to those functions), but that is not what I see in the
patch.  Moreover, the changes in read_char modify code more than is
necessary to handle the "at end of macro" situation, so we are risking
changes that will break something else.  Here's an example:

> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -2610,7 +2610,8 @@ read_char (int commandflag, Lisp_Object map,
>        goto reread_for_input_method;
>      }
>  
> -  if (!NILP (Vexecuting_kbd_macro))
> +  /* If we're executing a macro, process it unless we are at its end. */
> +  if (!NILP (Vexecuting_kbd_macro) && !at_end_of_macro_p ())
>      {
>        /* We set this to Qmacro; since that's not a frame, nobody will
>  	 try to switch frames on us, and the selected window will
> @@ -2624,15 +2625,6 @@ read_char (int commandflag, Lisp_Object map,
>  	 selected.  */
>        Vlast_event_frame = internal_last_event_frame = Qmacro;
>  
> -      /* Exit the macro if we are at the end.
> -	 Also, some things replace the macro with t
> -	 to force an early exit.  */
> -      if (at_end_of_macro_p ())
> -	{
> -	  XSETINT (c, -1);
> -	  goto exit;
> -	}
> -

This hunk moves the at_end_of_macro_p test to a higher level, which
has a side effect of not executing the code before the original
at_end_of_macro_p test -- how do we know this won't break something
that happens to depend on that code which will now not execute in the
at-end-of-macro case?

Also note that at least in subr.el we don't only test the -1 value, we
also test that a keyboard macro is being executed, and in this and
other callers that handle -1, each application behaves in
application-specific way when it receives -1.  It is not clear to me
how your changes modify the behavior in those cases, and your
explanations and the log message doesn't seem to answer this question.
For example, this code in calc-prog:

> --- a/lisp/calc/calc-prog.el
> +++ b/lisp/calc/calc-prog.el
> @@ -1230,8 +1230,6 @@ calc-kbd-skip-to-else-if
>  	ch)
>      (while (>= count 0)
>        (setq ch (read-char))
> -      (if (= ch -1)
> -	  (error "Unterminated Z[ in keyboard macro"))
>        (if (= ch ?Z)
>  	  (progn
>  	    (setq ch (read-char))

now signals a specific error in the case of an unterminated keyboard
macro: what will the behavior in that case be after the changes?

The questions I ask above are not theoretical -- we have been bitten
before, more than once or twice, by making seemingly innocuous changes
like this in keyboard.c, only to discover later, sometimes much later,
that some important use case became broken due to the change.  My take
from those incidents was that read_char and related code in keyboard.c
is a complex maze of code that should be touched only if we have a
very good reason, and then in a way that makes changes as localized as
possible to the very fragments we want to change.  In this case, given
that we want a more elegant solution for a situation that we already
handle, I tend to avoid any such changes to begin with, for the
reasons I explained above, and instead perhaps document the special
meaning of -1 in these cases.  And if we want to consider such changes
these dangers notwithstanding, I would like to see them affecting as
little other code as possible.  Can you suggest a safer changeset?

Adding Stefan to the discussion, in case he has comments.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#68272; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 5 Jan 2024 21:19:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 05 16:19:41 2024
Received: from localhost ([127.0.0.1]:58070 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rLrbQ-0001SO-BF
	for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 16:19:41 -0500
Received: from lists.gnu.org ([2001:470:142::17]:52118)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <crypto@HIDDEN>) id 1rLrbM-0001S9-Qa
 for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 16:19:38 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <crypto@HIDDEN>)
 id 1rLrbC-0003Zm-Ak
 for bug-gnu-emacs@HIDDEN; Fri, 05 Jan 2024 16:19:26 -0500
Received: from mout-p-201.mailbox.org ([80.241.56.171])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
 (Exim 4.90_1) (envelope-from <crypto@HIDDEN>)
 id 1rLrb5-00083l-OD
 for bug-gnu-emacs@HIDDEN; Fri, 05 Jan 2024 16:19:25 -0500
Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4T6GYC2kjyz9sZL
 for <bug-gnu-emacs@HIDDEN>; Fri,  5 Jan 2024 22:19:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timruffing.de;
 s=MBO0001; t=1704489551;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:mime-version:mime-version:content-type:content-type:autocrypt:autocrypt;
 bh=CWsG5HWoHoGdfY0bN7k2KKpUM7KpAitEvUHIGhjiwtE=;
 b=HdzdKyuhTgoKHQds+wHIlKvAW2BAT3NLlV4whrsZ64G9hqPNazcM4cYT8sFCdvOafkhl7O
 1SX4chU7JugrHE7kYtBRqgKNtSysiYBSxzRebeer5xqQwAR6kl+Nc8S88slPNt5/RV1CUw
 kKfDZLLZrvp5H0hjmXghlEjQJwe7949WFKPB7YzhX0iLCK+pTly/AEQJcfTj1gbjObaKJ/
 XvgInztFNb/MYf3Dcgq6Av2Rbv5t4Cal0t+59QAChPF3SyyageWdKhbf6ELvjzkm8Jgmr+
 hwJnBu7mw5n3OheFM0x+1XNZkSAmEHlhQUOZCGNQpN09GSMoo2wlWcTB3VcYYA==
Message-ID: <46480759b6d89b5a4864e8ee1b986817366a56e5.camel@HIDDEN>
Subject: [PATCH] Fix -1 leaking from C to lisp in 'read-event' etc.
From: Tim Ruffing <crypto@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Date: Fri, 05 Jan 2024 22:19:10 +0100
Autocrypt: addr=crypto@HIDDEN; prefer-encrypt=mutual;
 keydata=mQINBFz4LCMBEADLgtVg3uT+kybmXDPpXMvd8KBhTfAL5DP6umC9hkv/WHnfbCOUujhyvBljckcExAFr7tDYSgIjqa0L32SCT0NEaeY/s3WOYIacjBIEjTrgt01401lOWoX3XeYTWOlVUmUg+4iJPmBSPaj2bJR9Sq6NZhQjQ8K24VMtUNMiDeIIcstLkvQ4ZWkSuBUQJrJ0gUCZcUHNEyyGyZj1HOVGqGK7hTIiT1TfAgYKDDzk955LzgxbmATJWQLD7AGUIjKf/s418PTxI7Hh5ptH+Rq30+wkfvzJumYgkWUzeV6jzlOST5LkrFWQTfCXNvFNxSI9FVKjDIJZ7nQlgd+qNpGop90S3UqA8ofoG9liJm/jmbgIfJTgIiJpulycJD90PyJiWxtGshuZnHjCpkmU5vc1ZbuYyzH2wLoABSBsjy3Tb/25W2mnYnsOcVo1sWOGl+08Lb63ocVYGY27OrAIsv35pS/gMSGcJVg/EmPIM4+PmjeOxDlrJEW+8YzjKV9XtDv6VcBT1/OcA64knWC7JAGf0CGRodpolDjyfFRLOPV2/UbyOMJZjkxKTtV0je/RiMTupIHWcmimkvzpNo8D8U+Ac7KTPuPBrbj8EWeTbd/sK6bncjPL2DLomov0gCg/qlgObYmZ834+tQcThIBi3cj1cRj/0yKPy1uHgk2P2jO5i9AXGQARAQABtB9UaW0gUnVmZmluZyA8dGltQHRpbXJ1ZmZpbmcuZGU+iQJXBBMBCABBAhsBBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAhkBFiEECeA/hxCS5A4QbpArM7yGq4D/VRYFAmVV0QQFCQo+2GEACgkQM7yGq4D/VRZuVg/7Bga2TnJPDsAz5bULJciAcsb63mvxIVge75ShidoSNjJgJcdpkRLQYmb2O3XnJoiCnHQ3Ut6VI6uhMgoFo/zDKGaYAIDIlUL70+Q7LPJTvDhiT9ugRy+p+gdBX
 3iA9duadpJ6KScMVl4zbzmc4wqq50nIGxBKMhYtxv89jINhMyR/zZN+AIyCC0BBnpvbtPH7x07v3PI6LryW+5ZqDVeJYMvBMecaDxcjXYSXU3489LmShH7IdqQs9Tq8OWVTAOoOAkNy9kMwkKSyXuYFmKwhPiSY3InPxfd6Na+kQLjWyHpRH+DQs287B0LaJGOKexNxd57SO1B5f1am4HPzTmKjZMFL1JQFrAyb+XZY9tbXT8Ncqmy2VKVl/pfDVrBOGMp72zji8vRlp7ZJDlZzCXm5RV2P+APCN41IBPkSVesLj9iLYTvyu4o1SUOLz1PpNJdqbuKIyoPzOYWOdfb5cObJnZxGFpMopwSxhP77lAFmUnusiVx/GvMjj33Ro2D/jiS911D0PJ75pFrUY1xF2FVsMQsI6x/iPVk2DXtOR6RF0a0ioijS7+JT6rgosTl8dowsB6co3TYODYDc1j9R4/mZOMzJF27D6nYWmthx7zqg+VK4jm1k/IZIET0IIrHYoEzvDfnpDCKDc6D9cXFr2bGvYYxRBd2ZFciFjcBsXIpkEEa0IlRpbSBSdWZmaW5nIDxjcnlwdG9AdGltcnVmZmluZy5kZT6JAlQEEwEIAD4CGwEFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQQJ4D+HEJLkDhBukCszvIargP9VFgUCZVXRCAUJCj7YYQAKCRAzvIargP9VFt0OD/4/fGJ/pF4/CeXl0EfnruSxTjJi/60q5/CYmEbvFfG8eMyiOGlemVr021Gfzl1v5LMCDPa4NWb5bJA3tae88LPv2UO7+uD/z04gA52ZQm6nlkJhDrLacwKU+x4E0RsPf8lonF2FlKhOCbUaqlDwfoPjGVauhEBGfU6bUGQI1gzHEk9rzI6GsTCVo8Pc+RtqBOb73tdgOkj5gYqpTS/hKJd8lKp2DAQravMnK0sSLHw1fTXYW1+bcXi4GLd+Uw/ZjSxK8Rf0einckdOpS9
 7iuzPQ/MQ3163JDuUemQO0pseMfmvUgadCHT9PKs84cDukB7v7dYG6lAnBJtUONR3mOZn5lyLU2lv+5gE3pGr9tz1PY7by5/w+ttuYQdznoUz4sn+rSwAZQO6xoSJI9xCajtxjsHFEKcSOFNgiAIjJGXcZp3kdh1JPJ0iIv2fsqYo7TAxLLA2+86PQIwLe0nckog9pPTzKVar/pMlKf5/4926dwmGSBW1cwyfC8rY3qyOhao4gpA/EwxQnmWs1/+b0QQdiY4ktv80C5cMvk2LetzFELx+MMfeIXkPgriqXSsxK8gLNZqsYl9z96w+1tmXikKBS7GuJf+FJAdcQxw1gdLMp8t8FTFMN3QC5bot3jYOgC21n0CUxCTgbYv0ymKTojYdB06CVfu5YJoYqR0r5wUwQcLQiVGltIFJ1ZmZpbmcgPHB1YmxpY0B0aW1ydWZmaW5nLmRlPokCVAQTAQgAPgIbAQULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBAngP4cQkuQOEG6QKzO8hquA/1UWBQJlVdEIBQkKPthhAAoJEDO8hquA/1UWSoUQAIsiyIf7fqvwdGpkHAzkAbFipLfzcyp8su415ySdTrQTW29sTsyPIjN6r0RW0HSJWtPH43qgUgjRs+3fF0Obsdf9heNAY6KZmdyJ91rzbIWYOOGEAs4kqDwVMt5gBXz6N1eXYBVitjBaDRPCgq3sHUa3q5Vpo162UKgatIameThBrGgUFQhpUhbYKtp5161KRg2J4Iaz6sdcun31y27OMQdeT9o03RbQqmc6BXND/3h+aufOHDQov6vo87FrG4Qi86SRg5vQGOy0VPzU54X2Kf48oKiqBDKFcBaDljgryOL9e8i/Qmusr/YHwVZKwVerTxwGbftHIc7unlLTi4Ke6+XcseLd6SY7Cl6X2npuExaVd2fZ6UVa3qHoUf9uhN23JLLJHc5Pyf4evQ7J1Rulvz7BJPu8ctwNFBOBzfX
 6PhWm78OkNqMS8axCQ75HOz5xNJ24aGOumej+CyVvnop/aosjnRTfYWm8Xfjo7wu4uEF4XdeVPKp1XUY9nxWXksxvyXapYhVWdU3PlpJPD8ION28/QjPZtwNdKVmRtTrwd7hUDgJFr9GXGfsE+mQx84myde7n8AV5IOgTn45JYlCF8jay3lk+7cSqh6zHpbBdUPG9BFNACdLZUGmlZ0lj1QtLwXVr0Tm+5jvVlbYYbJJfoKUY7Ch8AvEf2FCBYmn0fb12uQINBFz4L28BEADdPI1M2yQTI/j1kyEkfOfvD22/DaHCmnFUkfYY7/2rij0QvWD11WL6ZSW9KcwPkufWBxftMyNlftIs3x177M7IyTNpzx3RKhL+iNgSeAilOxVZEq0aP5Y94T4h+w5Ck1vRKhceH97Yz7ubp2/07mD5tcb1n3EOg2Po412jjrE58PxXvQf14QMHLDLjiB9zcUjGYNQ+9EKQ4NU4kBqHtRByL4UfqtlHZTIDcjGBXFRCmztGVo9BoT6RydtIp67SQe06v5AFuFQeuBOv5AqObLCvL5tTo20AfQPm1f+H7tOecmdSPLbWR4Gs7KFBq3R3BUFIt90nq5h4iSygCbsXqYcQgcqR3AmtaJyrBX9OEFrRb+0DJEUgMt+ndAoY8l2VmtlHgKV4TovvRonhgCuEtxorJC0OUstrIHP47ilxnMEwJhd2oS3Hly7gw0Rsu9Xkgkge1NIGFLQvljeRmqsAYYrJkpBnaxcUXvQ4nBPJj5pdQhmFy+0q1IaTEWUqNI2JuPvt3MydXUqDZxGDd+IUA0GrBhV0R0zw16nNAsmH/OmtQLPVpUOuu8tOK7Z3E6P5m3FXIwnXH6piWpDfeqQmt/IJGKoQ6CLFTI4AgFbsRpTyN1RKK4HhytYPLIJPnWNnfF8e07T1Hv83LqMctjl/6RbmzGwRstMANFYKjRdUzdujOQARAQABiQI8BBgBCAAmAhsMFiEECeA/hxCS5A4Q
 bpArM7yGq4D/VRYFAmVV0RYFCQlK76cACgkQM7yGq4D/VRZmyBAAsJHjdiZqG7C+V5I2/sthUflMock6Se5xJ+bzhGoP7VwhdUcRNnKWUkZaj+jt4f3zckoPIB/RmVSfNXxzp9S0wJGpsqpudYUP97I4fkmyYxTiZFxYUVLv3vuYC4XF2PeSMg3jRKYQ2Zck+uju+TyUdQc2jpIgl/p87f/koxbhD2PkRn1gSU+PxqfVlNqxamrJaLNs7qwUOA4GTciy2IhWvFhvUSV/CXxhpvVFM+fFQD/dY5iP/LnzhqNMrHPj4VLdZMSZIdGyWdYUVP6MLU3WZ/Db5j37wdV93jNFi3wdSO/7jJZ29pGcX2b8W0nXsmfoL1SnRPVDAeI9VT1XF4kDWelDe6gJPVO1MiygSAGQ2sYsQq5LonQAgklAyXQ8P80HNdHTYBp4pR8lucSTcxGqALDXOdnuxPpEgFpy3tP78L7L/2AMZ5B2bYusBXeboGsLlsdTdNSN4cPRHyxR9u70b4sp1NsfwteeTEnUt6PLgwEEpaUn7LYltq1ejpWupRe15XnmehmDB5V8CxoLkpPEME4hr8F+3YxPLD68O591M1sc7Lc28X9O4EjBfx9lTstsezkB+F6mAKHlcp9fAbAG1dL84BBwXSn+ZR75YP5yNWcltFktWJ2YBsi7Vl1B/C2/OPPMxKoqlzoFiosucyNCMkQtgij0Tul4fFTeZ/DCda65Ag0EXPgvnQEQALnSCArYa7E9XRTSfxV+d5QyhZD11vRVgkH4OJfRTY+prjgmcB1+mIRZ4l3syiq81KeQGSmW0a2Ce8o0aF59DkgnFo1TMtGDzX/eZyxe/Fwuk7yNKAqR6MVLf/bnGSjhbBr4NefpWbHks2dkGBUbfzi0EocvxbwLZpLpumgtDLFKiot8VSj0hmmcz2uG9tAIKmM7rcXOMJbsNxI2fDPd0KoB61jOxkcT+AMtYIqxwd5ej8mWL5LsGDATz
 RZCIkOSUnHPeGrsYLR7ILqfFfSMdnXINu9UhuLSupmYVtm5g0zgFDn1u7XuJBp2epapfQ3EsQAYDFLRg1thJBT7h2Z4yyvWiGUiL07dyvpDDatkPUz8WgEBY0Fsnubpvfw9mslpPLabsARDJM76TvSNibcPxIeGgfr8GPV6qUNtWkqt0xrh90Di5IRb1u8kRxDt+aIir4Yq2J+2Ew/dtBs11HoDu84OC+8ck2gL0+TE9/dPm4yOF7eaKn7kkj+yT4I+aJtyhM2lQNME4vK8XJpgq3JPShlZPbYK/lLcHpFEBOrsDAJNwpc7iJYWJn6j3/Fiy5mKA68wIqbkOde+ZhgZXS51l94vLMM7tyhyDPd+4kSdzcLBcCc0lIzXDUe7cmXvjC/NwvjkoPuabM9H9VvhRea4t9Lc9hxSAaFoXZbq4omNOaoPABEBAAGJBHIEGAEIACYCGwIWIQQJ4D+HEJLkDhBukCszvIargP9VFgUCZVXRFgUJCUrveQJAwXQgBBkBCAAdFiEEAWT4Ukhg5KuhCfYse5ruiDUJqtgFAlz4L50ACgkQe5ruiDUJqthCwA/9GGMgxtD8hlel72mU7VVN79mzCmRTqpV4INR+kKX+kGW28rBTSxq1Cp2spaC1gbLNKFuiLQVjZ6la3CBfww6uRtUctU7k5edqiYgczsezNagNBOxP4EcVaK4ZWnRFdSceQck2ZCfSnYqI2k1FkcxOvBvRuMfxFaeeJ2VBo/+4vlGGjdvlr98Ewv1WgQv3ncvYDAbswM2KbD9wiZU1RMYvmpPCGzLE+mol2O3jWWDg7lrjdE0NOSSArBoYGi0qMYqA230IXmNWnc1l1LZLW9TETb94w+XaWHVgK7goKgNI+cQlzrZZ4cRSZx3x0Ws8gXXcMTqJ61+UjSUwfe3tIq5Nnt1juv3uaVL6GgxsrrLnHDf8BUi/dvprMuORbnCPfxDkwDe/GsZAxkk7JH1xtW0hU69bxtzQ7TlZKF
 t5GL+4vJMBlmODWZncrSzvLpr+itt3VfO4bNlMXadQ0nCn4gWHfH2RYUCKAavg0oqgcmS2KGSXaRvUd/2SCS29BC5OmRvCcPwrkwZE9iVX4zEgUk3l/8TKXronjwPHy8g/LGzLXb+qmYea1Dwt9wsyZmsniMA+ixBSN7nolflJ9hFIZzj2eTXj1WHK9Ye/xS3TktKFJ7nvg5C5TQxOkXRrZ8eXt4Ho6rQWoJtjThlQEdYygR/SG9OenDzkZu7qeCx+HEEyjGsJEDO8hquA/1UWPQgP/187VkxMx0WZazyekn4P/cXAKu2ox5RCzZaey1u79nYsbGDrBwwWQvLz9Gf97+nWeCU2RLqlM2oIIsiyAANOMevclBvAWygboFcfy1US6DMCj+b+ottsqujt+tx3nhTjvod4nyUkbnQGJgXV6q9WQK9c52J2VjexiR5RMqhhVybGDpttgu/8gu7vTQwF7jDi1FEm3xGsp069NNkoN4dcsHkpebgm1Bmzw9ULM5L6VLSqZpgj9mXGpfVFPLDXRbVoQFh2WtiF7RZIU20S6Vkmgvawn5DfE600W1CcgC/CxQX/SfBrLI5tAYqbAaQZrcWaOxqG1/PAFDxwCZQgxX4cw7LBPDpTHW+OUqL1yhRyWL5TSfxf+aXTO5lFPZaW82gyDL+sJhTTknnG7Zh+RZtDP7rhqR2YI7LNn9mG7XHnKai7Lr3IQ0lBeIh98dqCpCDawNARlKIamdWK5owCKCm2wsZAcpxEzEFFArHVklo1TXsnW3Ywoyb4c7TMdFjUhLhdcv+SIIUtUFHKoAlIkG0u15Fv5ZC7nLtwTrDuJW8hmQRw2k2y4TSbohWgDCV2/KSH1I/PflU+cze8WQeRQqmde2fWxSgPTA7ugSyBPkpGNdYQBFnuqfxezZDSTVzyh3DNpqsxGt8E560mC/KA+YNAAjGF0ePw7/Rh9sPXLFv88wFWuDMEXQT37RYJKwYBBAHaRw8BAQdAHPP
 jBVFc2oReNQB1+0rKKMjRCq6cU5jEl9jx+JlCvUKJArMEGAEIACYCGwIWIQQJ4D+HEJLkDhBukCszvIargP9VFgUCZVXRFgUJCT4nKQCBdiAEGRYIAB0WIQQABqSRH1VT5c4FNCGMRhzNKT9gEQUCXQT37QAKCRCMRhzNKT9gEYK1AP9g+AkebpYEqtNtHOyAuQJF/aTCNOXdPSBOtR5/y7iNVAEAl4aEB2Ofue9yjBBGOgRA65sGMxgEmI9PCU7kitqyoA8JEDO8hquA/1UWqm0QALM+y3hODe5/X7eSPHd36r2vaVXUKR3CPxr0yAZvcf3vKubyBagZKtFB49fYi8xZTe4iMd3Ozh8sHezWdb8f0/IMidmr+CD/NZg9OjFMNI+n/nmC1Qugdxq9ZbhohqftDEJirf3AMau/LVojjwsDi26r+/5nA3C9Iw4KVJqC3F/M1wq+fTJmj4Hd0tDHPapOtdfkposver/BzhnQ2fxKwejc0pI81ea2bBIoLcdC+aJ51W/GhzA0grWz8ssczP1JYgJIAlrthMYnTfGht6fLvD7hwr6vGoeI5V2yqci9dKdu5hTuWjWxNZBK12qMx+YN1s1mythxfRkHk2tOZ0am5BSSUw7Yn43TXlN9wc5pmguRhe3e7yC6tiHVJvl6pMP2lO8Ddmeqsf3C8WJwKYGzgnDGOQHcDZuSvFnRmS45D1DJ2MrDCepa9gSeFX/pbGsYuJrJklOMhMXffpgWlgwNWEaejxaLmhLt654NqFkBLo+aQTUkctH1Sf2FTCQOGBKfJXIZC8IzES7PT0r2E7UW+tJONb3dWenRKdBKppxqDVziLlfloEwRz1qGb/ZE1iQ/DHxa2IBkYLwDo0u7wzadA6AESNHJMcPHPPvEE7h0QJ/Pcl/MKjoI2LM3PKS1HE9nlnBN2lnfc6ZRMJapoA5cU0XbPsR7EAflLmYXKiJ+cIj4uE8EXPgwtBMFK4EEAAoCAwQwnnl1+/Yq
 AabnWn5xW3ux6PQE42O3KSDnFrSeROYQsnhY5DNAW3Zx+xRKBCHLvru785zMDsEmjpybZsb+i6OqiQKzBBgBCAAmAhsCFiEECeA/hxCS5A4QbpArM7yGq4D/VRYFAmVV0RYFCQlK7mIAgXYgBBkTCAAdFiEEtGU/qLvs74ko5Fi+s+HYaWSq3AwFAlz4MLQACgkQs+HYaWSq3AwVZAEAsFAzHbeIuSRb/D4+2hQL2m1HtnrDzKuI8zFT2Ryd0EgBAOcziZTKy+VIH3woL+EghEvjH3DPdTARuzYmgHbZMOqwCRAzvIargP9VFhefD/9RTbKteoaeYCJE0yn3KEa9J847C/nx/N6bPGomHslOEbhmIMknvfEwgppbRmnMhf3HeGaxsnpCDYNk4qrzrSrj7YtS5e4rCozjswJbA/MySx032Lm6fj6pAqe+yUbvOaKlyfcOQm0Rd7kTHjlCabnQWe1dDw3ihVnhpBwfjEYcQnttlhrGPUvdYI38dN9wSJTxme3EF9ZQJ9V74xJMTbS/GYTymabzQOcAk9VwzKyxBWR/x5wp1EDPMdBccMgYUKls7shCX0Kie1WqyjOIUqGVqRHecQPpnuXM+VLI/bqMUUfgMQbGHYFJJCgaLWkvTVKyLH7vdTeVDpgd6m+1voi2NXBtg9mgUx4XIItT8PbbveMxOrRwh2WDPX+lYLjXsG7IUCfdlSWEyZWMbljfNhPUrOtBm/blWHOrbGWrvGfkMWZZGD6dLAHSsQdoprp6OOT9gpEv5lQ7AKyl3jEPkHSsMDylHACi0Hd/xgKbrT9ir7ZKibUgCDcO3D9W+QMD0efKoWuPAY7vEQd8+mxIqH8BEcTiInsj4nu/xcw3eVWoFuQf3k85vF5O7qBbEX0fhwDGBTXEd7g5e87kXKV4KBZRLO4QpaRcvpJs7fBR3uxsbuE5cR5LugSkkSHJdZI2KossVMIbW5AoPw8Ov2/zrXStrJxS8eGs/Su6k1zh6
 7xWBA==
Content-Type: multipart/mixed; boundary="=-PUaU02Ozv+LlZk/Klo3Z"
MIME-Version: 1.0
Received-SPF: pass client-ip=80.241.56.171; envelope-from=crypto@HIDDEN;
 helo=mout-p-201.mailbox.org
X-Spam_score_int: -23
X-Spam_score: -2.4
X-Spam_bar: --
X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1,
 DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.6 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.4 (/)

--=-PUaU02Ozv+LlZk/Klo3Z
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

'read_char' in src/keyboard.c returns -1 to indicate the end of a
keyboard macro. This case is supposed to be propagated via=20
'read_key_sequence' and 'command_loop_2' to 'Fexecute_kbd_macro'.

But 'read_key_sequence' is not the only caller of 'read_char'. It is
also called by 'read-event' and similar lisp functions, and in that
case, the magic C return value -1 is wrongly propagated to the lisp
caller.=C2=A0

There are at least workarounds for this bug in at least three lisp
modules in the code base, in subr.el, in calc and most recently added
in dbus.el (bug #62018), see the attached patches. These patches are
supposed to resolve the underlying issue, and then remove the
workarounds.





--=-PUaU02Ozv+LlZk/Klo3Z
Content-Disposition: attachment;
	filename="0001-Extract-check-for-end-of-macro-to-function.patch"
Content-Type: text/x-patch; name="0001-Extract-check-for-end-of-macro-to-function.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

RnJvbSBmM2JkMGIzNDZlN2FhNDM1ZDc3OGU1NmI5YTdjNmExMjMzMTVkZjE4IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBUaW0gUnVmZmluZyA8Y3J5cHRvQHRpbXJ1ZmZpbmcuZGU+CkRh
dGU6IFdlZCwgMjcgRGVjIDIwMjMgMTQ6MjY6MjYgKzAxMDAKU3ViamVjdDogW1BBVENIIDEvNF0g
RXh0cmFjdCBjaGVjayBmb3IgZW5kIG9mIG1hY3JvIHRvIGZ1bmN0aW9uCgoqIHNyYy9tYWNyb3Mu
aCAoYXRfZW5kX29mX21hY3JvX3ApOgoqIHNyYy9tYWNyb3MuYyAoYXRfZW5kX29mX21hY3JvX3Ap
OgpOZXcgZnVuY3Rpb24uCiogc3JjL2tleWJvYXJkLmMgKHJlYWRfY2hhcik6IFVzZSB0aGUgbmV3
IGZ1bmN0aW9uLgotLS0KIHNyYy9rZXlib2FyZC5jIHwgIDMgKy0tCiBzcmMvbWFjcm9zLmMgICB8
IDEyICsrKysrKysrKysrKwogc3JjL21hY3Jvcy5oICAgfCAgNSArKysrKwogMyBmaWxlcyBjaGFu
Z2VkLCAxOCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9r
ZXlib2FyZC5jIGIvc3JjL2tleWJvYXJkLmMKaW5kZXggZTFkNzM4ZGQ2ZWYuLmQ0NzM2M2JjMzlm
IDEwMDY0NAotLS0gYS9zcmMva2V5Ym9hcmQuYworKysgYi9zcmMva2V5Ym9hcmQuYwpAQCAtMjYy
Nyw4ICsyNjI3LDcgQEAgcmVhZF9jaGFyIChpbnQgY29tbWFuZGZsYWcsIExpc3BfT2JqZWN0IG1h
cCwKICAgICAgIC8qIEV4aXQgdGhlIG1hY3JvIGlmIHdlIGFyZSBhdCB0aGUgZW5kLgogCSBBbHNv
LCBzb21lIHRoaW5ncyByZXBsYWNlIHRoZSBtYWNybyB3aXRoIHQKIAkgdG8gZm9yY2UgYW4gZWFy
bHkgZXhpdC4gICovCi0gICAgICBpZiAoRVEgKFZleGVjdXRpbmdfa2JkX21hY3JvLCBRdCkKLQkg
IHx8IGV4ZWN1dGluZ19rYmRfbWFjcm9faW5kZXggPj0gWEZJWE5BVCAoRmxlbmd0aCAoVmV4ZWN1
dGluZ19rYmRfbWFjcm8pKSkKKyAgICAgIGlmIChhdF9lbmRfb2ZfbWFjcm9fcCAoKSkKIAl7CiAJ
ICBYU0VUSU5UIChjLCAtMSk7CiAJICBnb3RvIGV4aXQ7CmRpZmYgLS1naXQgYS9zcmMvbWFjcm9z
LmMgYi9zcmMvbWFjcm9zLmMKaW5kZXggNWY3MWJjYmQzNjEuLjYyMTI5YmUxNjI5IDEwMDY0NAot
LS0gYS9zcmMvbWFjcm9zLmMKKysrIGIvc3JjL21hY3Jvcy5jCkBAIC0zNTMsNiArMzUzLDE4IEBA
IGluaXRfbWFjcm9zICh2b2lkKQogICBleGVjdXRpbmdfa2JkX21hY3JvID0gUW5pbDsKIH0KIAor
LyogV2hldGhlciB0aGUgZXhlY3V0aW9uIG9mIGEgbWFjcm8gaGFzIHJlYWNoZWQgaXRzIGVuZC4K
KyAgIEl0IG1ha2VzIG9ubHkgc2Vuc2UgdG8gY2FsbCB0aGlzIHdoZW4gd2hpbGUgZXhlY3V0aW5n
IGEgbWFjcm8uICAqLworCitib29sCithdF9lbmRfb2ZfbWFjcm9fcCAodm9pZCkKK3sKKyAgZWFz
c3VtZSAoIU5JTFAgKFZleGVjdXRpbmdfa2JkX21hY3JvKSk7CisgIC8qIFNvbWUgdGhpbmdzIHJl
cGxhY2UgdGhlIG1hY3JvIHdpdGggdCB0byBmb3JjZSBhbiBlYXJseSBleGl0LiAgKi8KKyAgcmV0
dXJuIEVRIChWZXhlY3V0aW5nX2tiZF9tYWNybywgUXQpCisgICAgfHwgZXhlY3V0aW5nX2tiZF9t
YWNyb19pbmRleCA+PSBYRklYTkFUIChGbGVuZ3RoIChWZXhlY3V0aW5nX2tiZF9tYWNybykpOwor
fQorCiB2b2lkCiBzeW1zX29mX21hY3JvcyAodm9pZCkKIHsKZGlmZiAtLWdpdCBhL3NyYy9tYWNy
b3MuaCBiL3NyYy9tYWNyb3MuaAppbmRleCA1MTU5OWEyOWJjZC4uNzg3MGFhNGRlMWQgMTAwNjQ0
Ci0tLSBhL3NyYy9tYWNyb3MuaAorKysgYi9zcmMvbWFjcm9zLmgKQEAgLTQ3LDQgKzQ3LDkgQEAg
I2RlZmluZSBFTUFDU19NQUNST1NfSAogCiBleHRlcm4gdm9pZCBzdG9yZV9rYmRfbWFjcm9fY2hh
ciAoTGlzcF9PYmplY3QpOwogCisvKiBXaGV0aGVyIHRoZSBleGVjdXRpb24gb2YgYSBtYWNybyBo
YXMgcmVhY2hlZCBpdHMgZW5kLgorICAgSXQgbWFrZXMgb25seSBzZW5zZSB0byBjYWxsIHRoaXMg
d2hlbiB3aGlsZSBleGVjdXRpbmcgYSBtYWNyby4gICovCisKK2V4dGVybiBib29sIGF0X2VuZF9v
Zl9tYWNyb19wICh2b2lkKTsKKwogI2VuZGlmIC8qIEVNQUNTX01BQ1JPU19IICovCi0tIAoyLjQz
LjAKCg==


--=-PUaU02Ozv+LlZk/Klo3Z
Content-Disposition: attachment;
	filename="0002-src-keyboard.c-requeued_events_pending_p-Revive.patch"
Content-Type: text/x-patch;
	name="0002-src-keyboard.c-requeued_events_pending_p-Revive.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

RnJvbSAyM2JjZWE0M2Q5YzU2ZTgyOWJmMjQ4Nzc2NTNkNTlhMDUxZTZjZDE5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBUaW0gUnVmZmluZyA8Y3J5cHRvQHRpbXJ1ZmZpbmcuZGU+CkRh
dGU6IFdlZCwgMjcgRGVjIDIwMjMgMTQ6Mjk6MzQgKzAxMDAKU3ViamVjdDogW1BBVENIIDIvNF0g
KiBzcmMva2V5Ym9hcmQuYyAocmVxdWV1ZWRfZXZlbnRzX3BlbmRpbmdfcCk6IFJldml2ZQoKKiBz
cmMva2V5Ym9hcmQuYyAocmVxdWV1ZWRfZXZlbnRzX3BlbmRpbmdfcCk6CkZpeCAncmVxdWV1ZWRf
ZXZlbnRzX3BlbmRpbmdfcCcgZnVuY3Rpb24gYnkgYWRkaW5nIG1pc3NpbmcKJ1Z1bnJlYWRfKl9l
dmVudCcgdmFyaWFibGVzLiBXaGVuICdyZXF1ZXVlZF9ldmVudHNfcGVuZGluZ19wJwp3YXMgYWRk
ZWQgKGNvbW1pdCBiMTg3OGY0NTA4NjgzNjVmMjdhZjBjNzE5MDAyMzcwNTZhNDRmOTAwKSwKJ1Z1
bnJlYWRfY29tbWFuZF9ldmVudHMnIHdhcyB0aGUgb25seSB2YXJpYWJsZSBvZiB0aGlzIGtpbmQu
CiogKEZpbnB1dF9wZW5kaW5nX3ApOiBBY3R1YWxseSB1c2UgdGhlIGNoYW5nZWQgZnVuY3Rpb24u
Ci0tLQogc3JjL2tleWJvYXJkLmMgfCAxMCArKysrKy0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgNSBp
bnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9rZXlib2FyZC5j
IGIvc3JjL2tleWJvYXJkLmMKaW5kZXggZDQ3MzYzYmMzOWYuLjA0MWI2MTZkOWFhIDEwMDY0NAot
LS0gYS9zcmMva2V5Ym9hcmQuYworKysgYi9zcmMva2V5Ym9hcmQuYwpAQCAtMTE1NTYsNyArMTE1
NTYsNyBAQCBjbGVhcl9pbnB1dF9wZW5kaW5nICh2b2lkKQogfQogCiAvKiBSZXR1cm4gdHJ1ZSBp
ZiB0aGVyZSBhcmUgcGVuZGluZyByZXF1ZXVlZCBldmVudHMuCi0gICBUaGlzIGlzbid0IHVzZWQg
eWV0LiAgVGhlIGhvcGUgaXMgdG8gbWFrZSB3YWl0X3JlYWRpbmdfcHJvY2Vzc19vdXRwdXQKKyAg
IEluIHRoZSBmdXR1cmUsIHRoZSBob3BlIGlzIHRvIG1ha2Ugd2FpdF9yZWFkaW5nX3Byb2Nlc3Nf
b3V0cHV0CiAgICBjYWxsIGl0LCBhbmQgcmV0dXJuIGlmIGl0IHJ1bnMgTGlzcCBjb2RlIHRoYXQg
dW5yZWFkcyBzb21ldGhpbmcuCiAgICBUaGUgcHJvYmxlbSBpcywga2JkX2J1ZmZlcl9nZXRfZXZl
bnQgbmVlZHMgdG8gYmUgZml4ZWQgdG8ga25vdyB3aGF0CiAgICB0byBkbyBpbiB0aGF0IGNhc2Uu
ICBJdCBpc24ndCB0cml2aWFsLiAgKi8KQEAgLTExNTY0LDcgKzExNTY0LDkgQEAgY2xlYXJfaW5w
dXRfcGVuZGluZyAodm9pZCkKIGJvb2wKIHJlcXVldWVkX2V2ZW50c19wZW5kaW5nX3AgKHZvaWQp
CiB7Ci0gIHJldHVybiAoQ09OU1AgKFZ1bnJlYWRfY29tbWFuZF9ldmVudHMpKTsKKyAgcmV0dXJu
IChDT05TUCAoVnVucmVhZF9jb21tYW5kX2V2ZW50cykKKwkgIHx8IENPTlNQIChWdW5yZWFkX3Bv
c3RfaW5wdXRfbWV0aG9kX2V2ZW50cykKKwkgIHx8IENPTlNQIChWdW5yZWFkX2lucHV0X21ldGhv
ZF9ldmVudHMpKTsKIH0KIAogREVGVU4gKCJpbnB1dC1wZW5kaW5nLXAiLCBGaW5wdXRfcGVuZGlu
Z19wLCBTaW5wdXRfcGVuZGluZ19wLCAwLCAxLCAwLApAQCAtMTE1NzUsOSArMTE1NzcsNyBAQCBE
RUZVTiAoImlucHV0LXBlbmRpbmctcCIsIEZpbnB1dF9wZW5kaW5nX3AsIFNpbnB1dF9wZW5kaW5n
X3AsIDAsIDEsIDAsCiBJZiBDSEVDSy1USU1FUlMgaXMgbm9uLW5pbCwgdGltZXJzIHRoYXQgYXJl
IHJlYWR5IHRvIHJ1biB3aWxsIGRvIHNvLiAgKi8pCiAgIChMaXNwX09iamVjdCBjaGVja190aW1l
cnMpCiB7Ci0gIGlmIChDT05TUCAoVnVucmVhZF9jb21tYW5kX2V2ZW50cykKLSAgICAgIHx8ICFO
SUxQIChWdW5yZWFkX3Bvc3RfaW5wdXRfbWV0aG9kX2V2ZW50cykKLSAgICAgIHx8ICFOSUxQIChW
dW5yZWFkX2lucHV0X21ldGhvZF9ldmVudHMpKQorICBpZiAocmVxdWV1ZWRfZXZlbnRzX3BlbmRp
bmdfcCAoKSkKICAgICByZXR1cm4gKFF0KTsKIAogICAvKiBQcm9jZXNzIG5vbi11c2VyLXZpc2li
bGUgZXZlbnRzIChCdWcjMTAxOTUpLiAgKi8KLS0gCjIuNDMuMAoK


--=-PUaU02Ozv+LlZk/Klo3Z
Content-Disposition: attachment;
	filename="0003-Fix-1-leaking-from-C-to-lisp-in-read-event-etc.patch"
Content-Type: text/x-patch;
	name="0003-Fix-1-leaking-from-C-to-lisp-in-read-event-etc.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

RnJvbSAyN2RiMDYyNWU1MzQ4ZDUwYmM1OTY3NGMwYThjOGQ0NWVkNGRiODc0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBUaW0gUnVmZmluZyA8Y3J5cHRvQHRpbXJ1ZmZpbmcuZGU+CkRh
dGU6IFdlZCwgMjcgRGVjIDIwMjMgMTQ6MzI6MDkgKzAxMDAKU3ViamVjdDogW1BBVENIIDMvNF0g
Rml4IC0xIGxlYWtpbmcgZnJvbSBDIHRvIGxpc3AgaW4gJ3JlYWQtZXZlbnQnIGV0Yy4KClRoaXMg
Zml4ZXMgYSBidWcgdGhhdCBjb3VsZCBtYWtlICdyZWFkLWV2ZW50JywgJ3JlYWQtY2hhcicsIGFu
ZAoncmVhZC1jaGFyLWV4Y2x1c2l2ZScgZXJyb25lb3VzbHkgcmV0dXJuIC0xLCBhbiBpbnRlcm5h
bCBtYWdpYyByZXR1cm4KdmFsdWUgb2YgJ3JlYWRfY2hhcicgbGVha2VkIGZyb20gQyB0byBsaXNw
LgoqIHNyYy9rZXlib2FyZC5jIChyZWFkX2NoYXIsIHJlYWRfa2V5X3NlcXVlbmNlKTogTW92ZSBo
YW5kbGluZwpvZiB0aGUgZW5kIG9mIGEga2V5Ym9hcmQgbWFjcm8gZnJvbSAncmVhZF9jaGFyJyB0
byBpdHMgY2FsbGVyCidyZWFkX2tleV9zZXF1ZW5jZScsIHdoaWNoIGlzIHRoZSBvbmx5IGNhbGxl
ciB0aGF0IGNhbgptZWFuaW5nZnVsbHkgZGVhbCB3aXRoIHRoaXMgY2FzZS4KLS0tCiBzcmMva2V5
Ym9hcmQuYyB8IDM5ICsrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogMSBm
aWxlIGNoYW5nZWQsIDE1IGluc2VydGlvbnMoKyksIDI0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp
dCBhL3NyYy9rZXlib2FyZC5jIGIvc3JjL2tleWJvYXJkLmMKaW5kZXggMDQxYjYxNmQ5YWEuLjli
NWUwMjAyMzhjIDEwMDY0NAotLS0gYS9zcmMva2V5Ym9hcmQuYworKysgYi9zcmMva2V5Ym9hcmQu
YwpAQCAtMjYxMCw3ICsyNjEwLDggQEAgcmVhZF9jaGFyIChpbnQgY29tbWFuZGZsYWcsIExpc3Bf
T2JqZWN0IG1hcCwKICAgICAgIGdvdG8gcmVyZWFkX2Zvcl9pbnB1dF9tZXRob2Q7CiAgICAgfQog
Ci0gIGlmICghTklMUCAoVmV4ZWN1dGluZ19rYmRfbWFjcm8pKQorICAvKiBJZiB3ZSdyZSBleGVj
dXRpbmcgYSBtYWNybywgcHJvY2VzcyBpdCB1bmxlc3Mgd2UgYXJlIGF0IGl0cyBlbmQuICovCisg
IGlmICghTklMUCAoVmV4ZWN1dGluZ19rYmRfbWFjcm8pICYmICFhdF9lbmRfb2ZfbWFjcm9fcCAo
KSkKICAgICB7CiAgICAgICAvKiBXZSBzZXQgdGhpcyB0byBRbWFjcm87IHNpbmNlIHRoYXQncyBu
b3QgYSBmcmFtZSwgbm9ib2R5IHdpbGwKIAkgdHJ5IHRvIHN3aXRjaCBmcmFtZXMgb24gdXMsIGFu
ZCB0aGUgc2VsZWN0ZWQgd2luZG93IHdpbGwKQEAgLTI2MjQsMTUgKzI2MjUsNiBAQCByZWFkX2No
YXIgKGludCBjb21tYW5kZmxhZywgTGlzcF9PYmplY3QgbWFwLAogCSBzZWxlY3RlZC4gICovCiAg
ICAgICBWbGFzdF9ldmVudF9mcmFtZSA9IGludGVybmFsX2xhc3RfZXZlbnRfZnJhbWUgPSBRbWFj
cm87CiAKLSAgICAgIC8qIEV4aXQgdGhlIG1hY3JvIGlmIHdlIGFyZSBhdCB0aGUgZW5kLgotCSBB
bHNvLCBzb21lIHRoaW5ncyByZXBsYWNlIHRoZSBtYWNybyB3aXRoIHQKLQkgdG8gZm9yY2UgYW4g
ZWFybHkgZXhpdC4gICovCi0gICAgICBpZiAoYXRfZW5kX29mX21hY3JvX3AgKCkpCi0JewotCSAg
WFNFVElOVCAoYywgLTEpOwotCSAgZ290byBleGl0OwotCX0KLQogICAgICAgYyA9IEZhcmVmIChW
ZXhlY3V0aW5nX2tiZF9tYWNybywgbWFrZV9pbnQgKGV4ZWN1dGluZ19rYmRfbWFjcm9faW5kZXgp
KTsKICAgICAgIGlmIChTVFJJTkdQIChWZXhlY3V0aW5nX2tiZF9tYWNybykKIAkgICYmIChYRklY
TkFUIChjKSAmIDB4ODApICYmIChYRklYTkFUIChjKSA8PSAweGZmKSkKQEAgLTEwNjg0LDggKzEw
Njc2LDE5IEBAIHJlYWRfa2V5X3NlcXVlbmNlIChMaXNwX09iamVjdCAqa2V5YnVmLCBMaXNwX09i
amVjdCBwcm9tcHQsCiAJICAgIH0KIAkgIHVzZWRfbW91c2VfbWVudSA9IHVzZWRfbW91c2VfbWVu
dV9oaXN0b3J5W3RdOwogCX0KLQotICAgICAgLyogSWYgbm90LCB3ZSBzaG91bGQgYWN0dWFsbHkg
cmVhZCBhIGNoYXJhY3Rlci4gICovCisgICAgICAvKiBJZiB3ZSdyZSBhdCB0aGUgZW5kIG9mIGEg
bWFjcm8sIGV4aXQgaXQgYnkgcmV0dXJuaW5nIDAsCisJIHVubGVzcyB0aGVyZSBhcmUgdW5yZWFk
IGV2ZW50cyBwZW5kaW5nLiAgKi8KKyAgICAgIGVsc2UgaWYgKCFOSUxQIChWZXhlY3V0aW5nX2ti
ZF9tYWNybykKKwkgICYmIGF0X2VuZF9vZl9tYWNyb19wICgpCisJICAmJiAhcmVxdWV1ZWRfZXZl
bnRzX3BlbmRpbmdfcCAoKSkKKwl7CisJICB0ID0gMDsKKwkgIC8qIFRoZSBNaWNyb3NvZnQgQyBj
b21waWxlciBjYW4ndCBoYW5kbGUgdGhlIGdvdG8gdGhhdAorCSAgICAgd291bGQgZ28gaGVyZS4g
ICovCisJICBkdW1teWZsYWcgPSB0cnVlOworCSAgYnJlYWs7CisJfQorICAgICAgLyogT3RoZXJ3
aXNlLCB3ZSBzaG91bGQgYWN0dWFsbHkgcmVhZCBhIGNoYXJhY3Rlci4gICovCiAgICAgICBlbHNl
CiAJewogCSAgewpAQCAtMTA3NzcsMTggKzEwNzgwLDYgQEAgcmVhZF9rZXlfc2VxdWVuY2UgKExp
c3BfT2JqZWN0ICprZXlidWYsIExpc3BfT2JqZWN0IHByb21wdCwKIAkgICAgICByZXR1cm4gLTE7
CiAJICAgIH0KIAotCSAgLyogcmVhZF9jaGFyIHJldHVybnMgLTEgYXQgdGhlIGVuZCBvZiBhIG1h
Y3JvLgotCSAgICAgRW1hY3MgMTggaGFuZGxlcyB0aGlzIGJ5IHJldHVybmluZyBpbW1lZGlhdGVs
eSB3aXRoIGEKLQkgICAgIHplcm8sIHNvIHRoYXQncyB3aGF0IHdlJ2xsIGRvLiAgKi8KLQkgIGlm
IChGSVhOVU1QIChrZXkpICYmIFhGSVhOVU0gKGtleSkgPT0gLTEpCi0JICAgIHsKLQkgICAgICB0
ID0gMDsKLQkgICAgICAvKiBUaGUgTWljcm9zb2Z0IEMgY29tcGlsZXIgY2FuJ3QgaGFuZGxlIHRo
ZSBnb3RvIHRoYXQKLQkJIHdvdWxkIGdvIGhlcmUuICAqLwotCSAgICAgIGR1bW15ZmxhZyA9IHRy
dWU7Ci0JICAgICAgYnJlYWs7Ci0JICAgIH0KLQogCSAgLyogSWYgdGhlIGN1cnJlbnQgYnVmZmVy
IGhhcyBiZWVuIGNoYW5nZWQgZnJvbSB1bmRlciB1cywgdGhlCiAJICAgICBrZXltYXAgbWF5IGhh
dmUgY2hhbmdlZCwgc28gcmVwbGF5IHRoZSBzZXF1ZW5jZS4gICovCiAJICBpZiAoQlVGRkVSUCAo
a2V5KSkKLS0gCjIuNDMuMAoK


--=-PUaU02Ozv+LlZk/Klo3Z
Content-Disposition: attachment;
	filename="0004-Remove-workarounds-for-solved-read-event-bug.patch"
Content-Type: text/x-patch;
	name="0004-Remove-workarounds-for-solved-read-event-bug.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

RnJvbSBlNzNlMDg5Mjc3OTIzMDMwMTNhOGE5OTM1NjU2MzY1ZjlmMjI5OWI2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBUaW0gUnVmZmluZyA8Y3J5cHRvQHRpbXJ1ZmZpbmcuZGU+CkRh
dGU6IFdlZCwgMjcgRGVjIDIwMjMgMTQ6MzI6MDkgKzAxMDAKU3ViamVjdDogW1BBVENIIDQvNF0g
UmVtb3ZlIHdvcmthcm91bmRzIGZvciBzb2x2ZWQgJ3JlYWQtZXZlbnQnIGJ1ZwoKKiBsaXNwL3N1
YnIuZWwgKHJlYWQtY2hhci1jaG9pY2Utd2l0aC1yZWFkLWtleSk6CiogbGlzcC9uZXQvZGJ1cy5l
bCAoZGJ1cy1jYWxsLW1ldGhvZCk6CiogbGlzcC9jYWxjL2NhbGMtcHJvZy5lbDoKUmVtb3ZlIHdv
cmthcm91bmRzIGZvciB0aGUgYnVnIGZpeGVkIGluIHRoZSBwcmV2aW91cyBjb21taXQKYWM4MmJh
ZWExYzQxZWM5NzRhZDQ5ZjI4NjFhZTZjMDZiZGEyYjRlZCwgd2hlcmUgJ3JlYWQtZXZlbnQnLAon
cmVhZC1jaGFyJyBhbmQgJ3JlYWQtY2hhci1leGNsdXNpdmVseScgY291bGQgcmV0dXJuIHdyb25n
bHkgLTEuCkluIHRoZSBjYXNlIG9mIGxpc3AvZGJ1cy5lbCwgdGhpcyByZXZlcnRzIGNvbW1pdAo3
MTc3MzkzODI2YzczYzg3ZmZlOWI0MjhmMGU1ZWRhZTI0NGQ3YTk4LgotLS0KIGxpc3AvY2FsYy9j
YWxjLXByb2cuZWwgfCA2IC0tLS0tLQogbGlzcC9uZXQvZGJ1cy5lbCAgICAgICB8IDYgKy0tLS0t
CiBsaXNwL3N1YnIuZWwgICAgICAgICAgIHwgNSAtLS0tLQogMyBmaWxlcyBjaGFuZ2VkLCAxIGlu
c2VydGlvbigrKSwgMTYgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9jYWxjL2NhbGMt
cHJvZy5lbCBiL2xpc3AvY2FsYy9jYWxjLXByb2cuZWwKaW5kZXggMDMyMTA5OTVlYjMuLjE3N2Mx
Nzk0MzNkIDEwMDY0NAotLS0gYS9saXNwL2NhbGMvY2FsYy1wcm9nLmVsCisrKyBiL2xpc3AvY2Fs
Yy9jYWxjLXByb2cuZWwKQEAgLTEyMzAsOCArMTIzMCw2IEBAIGNhbGMta2JkLXNraXAtdG8tZWxz
ZS1pZgogCWNoKQogICAgICh3aGlsZSAoPj0gY291bnQgMCkKICAgICAgIChzZXRxIGNoIChyZWFk
LWNoYXIpKQotICAgICAgKGlmICg9IGNoIC0xKQotCSAgKGVycm9yICJVbnRlcm1pbmF0ZWQgWlsg
aW4ga2V5Ym9hcmQgbWFjcm8iKSkKICAgICAgIChpZiAoPSBjaCA/WikKIAkgIChwcm9nbgogCSAg
ICAoc2V0cSBjaCAocmVhZC1jaGFyKSkKQEAgLTEzMDAsOCArMTI5OCw2IEBAIGNhbGMta2JkLWxv
b3AKIAkobWVzc2FnZSAiUmVhZGluZyBsb29wIGJvZHkuLi4iKSkKICAgICAod2hpbGUgKD49IGNv
dW50IDApCiAgICAgICAoc2V0cSBjaCAocmVhZC1ldmVudCkpCi0gICAgICAoaWYgKGVxIGNoIC0x
KQotCSAgKGVycm9yICJVbnRlcm1pbmF0ZWQgWiVjIGluIGtleWJvYXJkIG1hY3JvIiBvcGVuKSkK
ICAgICAgIChpZiAoZXEgY2ggP1opCiAJICAocHJvZ24KIAkgICAgKHNldHEgY2ggKHJlYWQtZXZl
bnQpCkBAIC0xNDI4LDggKzE0MjQsNiBAQCBjYWxjLWtiZC1wdXNoCiAJICAgICAgIChtZXNzYWdl
ICJSZWFkaW5nIGJvZHkuLi4iKSkKIAkgICAod2hpbGUgKD49IGNvdW50IDApCiAJICAgICAoc2V0
cSBjaCAocmVhZC1jaGFyKSkKLQkgICAgIChpZiAoPSBjaCAtMSkKLQkJIChlcnJvciAiVW50ZXJt
aW5hdGVkIFpgIGluIGtleWJvYXJkIG1hY3JvIikpCiAJICAgICAoaWYgKD0gY2ggP1opCiAJCSAo
cHJvZ24KIAkJICAgKHNldHEgY2ggKHJlYWQtY2hhcikKZGlmZiAtLWdpdCBhL2xpc3AvbmV0L2Ri
dXMuZWwgYi9saXNwL25ldC9kYnVzLmVsCmluZGV4IDc3YjMzNGU3MDRlLi40NmY4NWRhYmEyNCAx
MDA2NDQKLS0tIGEvbGlzcC9uZXQvZGJ1cy5lbAorKysgYi9saXNwL25ldC9kYnVzLmVsCkBAIC0z
NzEsMTEgKzM3MSw3IEBAIGRidXMtY2FsbC1tZXRob2QKIAkgKGFwcGx5CiAgICAgICAgICAgIydk
YnVzLW1lc3NhZ2UtaW50ZXJuYWwgZGJ1cy1tZXNzYWdlLXR5cGUtbWV0aG9kLWNhbGwKICAgICAg
ICAgICBidXMgc2VydmljZSBwYXRoIGludGVyZmFjZSBtZXRob2QgIydkYnVzLWNhbGwtbWV0aG9k
LWhhbmRsZXIgYXJncykpCi0gICAgICAgIChyZXN1bHQgKHVubGVzcyBleGVjdXRpbmcta2JkLW1h
Y3JvIChjb25zIDpwZW5kaW5nIG5pbCkpKSkKLQotICAgIDs7IFdoaWxlIGV4ZWN1dGluZyBhIGtl
eWJvYXJkIG1hY3JvLCB3ZSBydW4gaW50byBhbiBpbmZpbml0ZSBsb29wLAotICAgIDs7IHJlY2Vp
dmluZyB0aGUgZXZlbnQgLTEuICBTbyB3ZSBkb24ndCB0cnkgdG8gZ2V0IHRoZSByZXN1bHQuCi0g
ICAgOzsgKEJ1ZyM2MjAxOCkKKyAgICAgICAgKHJlc3VsdCAoY29ucyA6cGVuZGluZyBuaWwpKSkK
IAogICAgIDs7IFdhaXQgdW50aWwgYGRidXMtY2FsbC1tZXRob2QtaGFuZGxlcicgaGFzIHB1dCB0
aGUgcmVzdWx0IGludG8KICAgICA7OyBgZGJ1cy1yZXR1cm4tdmFsdWVzLXRhYmxlJy4gIElmIG5v
IHRpbWVvdXQgaXMgZ2l2ZW4sIHVzZSB0aGUKZGlmZiAtLWdpdCBhL2xpc3Avc3Vici5lbCBiL2xp
c3Avc3Vici5lbAppbmRleCBkZjI4OTg5YjM5OS4uNzhlN2ZmYmM5NzkgMTAwNjQ0Ci0tLSBhL2xp
c3Avc3Vici5lbAorKysgYi9saXNwL3N1YnIuZWwKQEAgLTM1MzksMTEgKzM1MzksNiBAQCByZWFk
LWNoYXItY2hvaWNlLXdpdGgtcmVhZC1rZXkKIAkJIChoZWxwLWZvcm0tc2hvdykpKQogCSAgICgo
bWVtcSBjaGFyIGNoYXJzKQogCSAgICAoc2V0cSBkb25lIHQpKQotCSAgICgoYW5kIGV4ZWN1dGlu
Zy1rYmQtbWFjcm8gKD0gY2hhciAtMSkpCi0JICAgIDs7IHJlYWQtZXZlbnQgcmV0dXJucyAtMSBp
ZiB3ZSBhcmUgaW4gYSBrYmQgbWFjcm8gYW5kCi0JICAgIDs7IHRoZXJlIGFyZSBubyBtb3JlIGV2
ZW50cyBpbiB0aGUgbWFjcm8uICBBdHRlbXB0IHRvCi0JICAgIDs7IGdldCBhbiBldmVudCBpbnRl
cmFjdGl2ZWx5LgotCSAgICAoc2V0cSBleGVjdXRpbmcta2JkLW1hY3JvIG5pbCkpCiAJICAgKChu
b3QgaW5oaWJpdC1rZXlib2FyZC1xdWl0KQogCSAgICAoY29uZAogCSAgICAgKChhbmQgKG51bGwg
ZXNjLWZsYWcpIChlcSBjaGFyID9cZSkpCi0tIAoyLjQzLjAKCg==


--=-PUaU02Ozv+LlZk/Klo3Z--




Acknowledgement sent to Tim Ruffing <crypto@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#68272; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sat, 20 Jan 2024 12:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.