From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21188 invoked by alias); 10 Feb 2006 15:26:08 -0000 Received: (qmail 21178 invoked by uid 22791); 10 Feb 2006 15:26:08 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 10 Feb 2006 15:26:06 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F7a9q-0006Hu-GK; Fri, 10 Feb 2006 10:26:02 -0500 Date: Fri, 10 Feb 2006 15:26:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI error messages Message-ID: <20060210152602.GA24109@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Vladimir Prus , gdb@sources.redhat.com References: <20060210134700.GA21328@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00082.txt.bz2 On Fri, Feb 10, 2006 at 05:22:31PM +0200, Eli Zaretskii wrote: > > I don't think the function name adds much value in user-level error > > messages. > > MI is not a user-level protocol, it's a machine-level protocol. What > is displayed to the user as a result is another matter. These are just the result of calls to error (). Admittedly, many of them are for mistakes that a GUI shouldn't be making - but some can easily come from user input, so when you get one, I don't think you've got much choice but to display it to the user. > > It is certainly not guaranteed; there's no separation between "MI error > > messages" and "other GDB error messages" since an MI session can > > reach just about any call to error() in the sources. > > We should either have all or none of the MI messages state the > function. A machine-oriented interface must be consistent, IMO. Then they'll have to go unless you want error () to automatically collect the function (not very useful, IMO). -- Daniel Jacobowitz CodeSourcery