From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27286 invoked by alias); 19 Dec 2006 23:20:03 -0000 Received: (qmail 27229 invoked by uid 22791); 19 Dec 2006 23:20:02 -0000 X-Spam-Check-By: sourceware.org Received: from 195.22.55.53.adsl.nextra.cz (HELO host0.dyn.jankratochvil.net) (195.22.55.53) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Dec 2006 23:19:57 +0000 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.13.8/8.13.8) with ESMTP id kBJNJRrI021121; Wed, 20 Dec 2006 00:19:27 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.13.8/8.13.8/Submit) id kBJNJRrD021120; Wed, 20 Dec 2006 00:19:27 +0100 Date: Tue, 19 Dec 2006 23:20:00 -0000 From: Jan Kratochvil To: Chet Ramey Cc: "H. J. Lu" , GDB , bug-readline@gnu.org Subject: Re: PATCH: PR tui/2173: Arrow keys no longer works in breakpoint command list Message-ID: <20061219231926.GA20632@host0.dyn.jankratochvil.net> 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> <4586F56F.5040304@case.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4586F56F.5040304@case.edu> User-Agent: Mutt/1.4.2.2i X-IsSubscribed: yes 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/msg00258.txt.bz2 Hi Chet, On Mon, 18 Dec 2006 21:09:19 +0100, Chet Ramey wrote: ... > 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. OK, so going to provide callback based GDB reimplementation of gdb_readline_wrapper () (readline () call). > > 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. rl_read_key () calls _rl_next_macro_key () and rl_read_key () can be called by the application. I did not check how much serious is a fail of this mode check but I assume there are other functions callable by the application this way. Regards, Jan