From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29297 invoked by alias); 14 Feb 2006 21:05:12 -0000 Received: (qmail 29289 invoked by uid 22791); 14 Feb 2006 21:05:12 -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; Tue, 14 Feb 2006 21:05:11 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F97M9-0000Eg-4r; Tue, 14 Feb 2006 16:05:05 -0500 Date: Tue, 14 Feb 2006 21:05:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Bjarke Viksoe , gdb@sourceware.org Subject: Re: MI error msgs and localization Message-ID: <20060214210505.GA817@nevyn.them.org> Mail-Followup-To: Nick Roberts , Bjarke Viksoe , gdb@sourceware.org References: <17393.12925.270558.512941@kahikatea.snap.net.nz> <17394.17519.510199.853654@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17394.17519.510199.853654@kahikatea.snap.net.nz> 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/msg00146.txt.bz2 On Wed, Feb 15, 2006 at 09:58:23AM +1300, Nick Roberts wrote: > > I don't particular like to hard-code these strings. The list of messages I > > gave previously are all marked as console-stream-output. What I am saying is > > that localizing such error messages will hurt MI dependant tools since the > > messages are highly useful for the front-end. I'm not sure what purpose > > console-output really has in a Machine Interface as it tends to make sense > > only to humans - but I guess some systems are making use of them. > > > > What I'd really like is to see them also wrapped in result-records (sample; > > ignore syntax): > > > > ^failed,type="init-option-unrecognized",msg="Unrecognized option" > > > > Does that make any sense? > > We've already got ^error as a result field so it doesn't make any sense to me, > and if "Unrecognized option" comes from the console stream then I think that > can still change. The problem seems to be that of handling CLI error output > in MI. I see that the standard GNU error function provides for an error > number which is less likely to change: > > -- Function: void error (int STATUS, int ERRNUM, const char *FORMAT, > ...) > > I wonder if GDB's error function could have one for MI e.g > > &"Unrecognized option\n" > ^error,msg="Unrecognized option",code="35" > > or even > > &"Unrecognized option\n" > ^error,code="35" > > instead of just: > > &"Unrecognized option\n" > ^error,msg="Unrecognized option" GCC developers spent a lot of time talking about this. I think the trick to doing this right is actually to do it the way Bjarke suggested: msg= as a free-form, explanatory text, and type= (or code=, or something else) as a documented identifier. But using numbers for the identifiers is not necessarily a good idea, because keeping track of them is error-prone. I'd suggest that type="init-option-unrecognized" was a lot more memorable than "code=35". We have to be careful what error messages get identifiers, though. Please don't anybody go through the source indiscriminately adding them. Many errors will still be subject to change even if you tack permanent identifiers on them. -- Daniel Jacobowitz CodeSourcery