On 4/29/16 10:53 PM, [email protected] wrote: > Hi Chet, > > Thank you for the advice. I think it would just be good to update the > callback interface example in Readline to have this code, so that we > can see how it is done in context. I think it would be good to have > some short example programs for both the basic 'readline()' interface > and for the callback interface, which > > 1. handle SIGWINCH correctly > 2. handle SIGINT in the same way as Bash, by clearing the line > > Do you have any idea when you'll have time to finalize these?
I will get to them when it bubbles to the top of the priority list. > > I still have a lot of confusion, for instance I noticed a recent > message on this list where you say: > >> This is probably the result of the same signal handling issues as with >> SIGWINCH that we discussed a little more than a year ago. Readline >> catches the signal, sets a flag, and, when it's safe, resends it to the >> calling application. It expects that if the calling application catches >> SIGINT, it will take care of cleaning up the readline state. Sometimes >> applications don't want to kill the current line on SIGINT. > > As I understand it, if the application ignores SIGINT with SIG_IGN, > then Readline will ignore it too. But if the application traps SIGINT, > then Readline will catch it and pass it on to the application. When > Readline next gets control it will call rl_free_line_state(), which > deletes the undo list, clears the message area, and cancels any > keyboard macros. You said "Sometimes applications don't want to kill > the current line on SIGINT" but (1) do you know of any examples? Sure. An interactive bash with line editing active that traps SIGINT. (2) > Why would such an application want Readline to delete the undo list, > clear the message area, and cancel any keyboard macros, if it is not > going to clear the line? I think application writers expect the line > to be cleared, for example see: Deleting the undo list might be iffy, but the others seem reasonable. > > http://stackoverflow.com/questions/16828378/readline-get-a-new-prompt-on-sigint > > Now, in the above Stackoverflow discussion, the poster is using the > basic 'readline()' interfac. He solves the problem by using a > 'siglongjmp' to get out of the SIGINT handler. Apparently user > "jancheta" thinks that by using 'siglongjmp' instead of 'longjmp', the > code will be safe from race conditions: "But because the longjmp would > be in a signal handler, you need to use sigsetjmp/siglongjmp". I don't > understand how this could be - if the signal arrives in the middle of > a malloc(), then won't we still be corrupting some global state? Neither longjmp nor siglongjmp is on the list of signal-safe functions. > > (Please let me know if I'm mistaken about this. Does glibc block > SIGINT around functions like malloc()?) No. glibc blocks SIGINT very rarely, but uses locks pervasively. > > So apparently in addition to the isearch-SIGINT bug which affects the > callback interface (creating a dangerous situation which causes > undesired lines to be entered at the prompt!) there is also a problem > in that users of the basic readline() interface don't even know how to > safely achieve the familiar behavior of clearing a line on ^C. Take a breath. In this case, siglongjmp is probably ok, since you know you're not interrupting any unsafe calls in the readline library code. All the code I posted is safe to execute from a signal handler. You can clear the line by either running rl_done = 1 or rl_line_buffer[rl_point = rl_end = rl_mark = 0] = 0; It's the clearing readline state that's the bug. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU [email protected] http://cnswww.cns.cwru.edu/~chet/ _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
