Re: pending signal after rl_callback_read_char

[Chet Ramey]

On 9/16/22 10:25 AM, Tom de Vries wrote:
> Hi,
>
> with gdb we've run into a PR ( 
> https://sourceware.org/bugzilla/show_bug.cgi?id=27813 ) where the call to 
> rl_callback_read_char returns with rl_pending_signal () != 0 after pressing 
> ^C.

Thanks for the report. I don't quite buy the analysis in comment 9
(https://sourceware.org/bugzilla/show_bug.cgi?id=27813#c9).

You're saying that readline is still in rl_callback_read_char *after*
reading \t and attempting completion, right? Then expect sends ^C, so
either the next call or, depending on timing, whether something pushed
input into rl_pending_input and it's the same call. Nothing complicated
with any registered callback functions. It does mean that gdb is calling
rl_callback_read_char without any input available and relying on it to
block until some is, but that's ok.

So let's say readline_internal_char ran _rl_dispatch() (why?), and is in
_rl_internal_char_cleanup() when the signal arrives (after it's checked
for signals with RL_CHECK_SIGNALS()). I'm not sure what caused it to
return from rl_read_key() if the signal didn't arrive until then, but ok.

So say _rl_internal_char_cleanup() returns 0 without the abort() you added.
I assume it's been called by rl_callback_read_char() in this call:

        eof = readline_internal_char ();

The first thing rl_callback_read_char does after that is
RL_CHECK_SIGNALS(). You'd think that would do the trick. If
rl_callback_read_char is returning from some other path, I'd like to see
it. It's not apparent from that trace.

Another two questions: what is rl_done  set to when rl_callback_read_char()
returns? I assume 0. And what is rl_readline_state set to?

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/