From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1682 invoked by alias); 18 Dec 2006 20:09:58 -0000 Received: (qmail 1628 invoked by uid 22791); 18 Dec 2006 20:09:55 -0000 X-Spam-Check-By: sourceware.org Received: from mpv4.TIS.CWRU.Edu (HELO mpv4.tis.cwru.edu) (129.22.105.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 20:09:43 +0000 Received: from [129.22.8.211] (caleb.INS.CWRU.Edu [129.22.8.211]) by mpv4.tis.cwru.edu (MOS 3.8.2-GA) with ESMTP id BXI62206 (AUTH cpr); Mon, 18 Dec 2006 15:09:19 -0500 (EST) Message-ID: <4586F56F.5040304@case.edu> Date: Mon, 18 Dec 2006 20:09:00 -0000 From: Chet Ramey Reply-To: chet.ramey@case.edu User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Jan Kratochvil CC: "H. J. Lu" , GDB , bug-readline@gnu.org, chet@case.edu Subject: Re: PATCH: PR tui/2173: Arrow keys no longer works in breakpoint command list References: <20061121213205.GA13310@lucon.org> <20061128164658.GB20882@nevyn.them.org> <20061128165844.GA13667@lucon.org> <20061202184344.GA2197@lucon.org> <4571CF2A.3040608@case.edu> <20061202221541.GA9776@lucon.org> <45725FC9.9070304@case.edu> <20061217234530.GA20773@host0.dyn.jankratochvil.net> In-Reply-To: <20061217234530.GA20773@host0.dyn.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00242.txt.bz2 Jan Kratochvil wrote: > On Sun, 03 Dec 2006 06:25:29 +0100, Chet Ramey wrote: > ... >> More appropriate in the sense that the application controls the state >> and switches between the callback and synchronous readline modes. >> Since it's the app that's supposed to be calling into readline when in >> callback mode anyway, I think this patch will work better. > > Chet, is it right it is more a design than implementation problem of readline? > readline cannot determine how many nested readline calls have been abandoned by > signal handler's longjmp (). Therefore it cannot determine if the current mode > (the last unabandoned call) is a callback or synchronous one. Not exactly. The callback and traditional calling mechanisms are orthogonal. It's just not safe to mix them. The longjmp leaves readline in an inconsistent state, unless the calling application is careful to undo what state-setting it has done. That's the part readline can't know about: the appropriate application-specific part. > > The sample code should be readline documentation compliant, still the called > function `_rl_next_macro_key' has undeterministic value of > `RL_ISSTATE (RL_STATE_CALLBACK)'. OK, you got me. I'll fix that one, if I can find it. I can't find a call to that function in the examples/ or doc/ directories. > Also any longjmp () from inside a signal handler is too dangerous as the data > structures are not locked against signals. The signal handler should only set > some flag. And the synchronous readline () function should be never used if > one needs to quit the input mode by SIGINT (as one cannot abort readline () if > not using the dangerous longjmp ()). Sure, in theory. Pragmatically, however, it's not that bad. We're just talking about not mixing the two calling modes, since readline alters its behavior (and makes certain assumptions) based on the current mode. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/