From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24355 invoked by alias); 10 Feb 2006 20:17:43 -0000 Received: (qmail 24339 invoked by uid 22791); 10 Feb 2006 20:17:41 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Feb 2006 20:17:39 +0000 Received: from kahikatea.snap.net.nz (p202-124-114-114.snap.net.nz [202.124.114.114]) by viper.snap.net.nz (Postfix) with ESMTP id 4656C741058; Sat, 11 Feb 2006 09:17:34 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 7C6D48887; Sat, 11 Feb 2006 09:16:40 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17388.62632.330005.663964@kahikatea.snap.net.nz> Date: Fri, 10 Feb 2006 20:17:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: MI error messages In-Reply-To: References: 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/msg00090.txt.bz2 > Below is a short MI session: > > (gdb) -var-assign KDEVTMP br > &"mi_cmd_var_assign: Could not assign expression to varible object\n" > ^error,msg="mi_cmd_var_assign: Could not assign expression to varible > > The good thing about this is that I can easily detect that's an error, and > show a message to the user. The bad thing is that the message includes > 'mi_cmd_var_assign:' part. For end user of KDevelop, or even end user of > gdb, this makes no sense -- it's the name of internal function. It can only > confuse. In June of last year there was a thread ([PATCH] MI error messages) about this subject (see archives). I think it was similarly suggested that the procedure name was unnecessary. Some error messages are for the user, and some should only occur if there is a bug in the front end and should never really be seen by the user. The example you give above is the latter. I think these shouldn't also get reported on the log/error stream (prefixed with &). In the end we didn't resolve the issue and nothing was changed. > So, could somebody tell: > > 1. Is it guaranteed that all MI error message start with function name and a > semicolon? Not currently, look at the sources. > 2. If not, is there any regexp that can be used to remove the function name, > that's guaranteed to work for all current and future MI error messages. > Removing anything before first semicolon is risky -- error message can > contain ':' for other reasons. If you are going to rely on any syntax, you need to check current messages and document any rules for future reference. > 3. If not, can the function name be removed? I think error reporting needs to be overhauled. Many changes could be made, removing function names is one of them. Nick