From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22084 invoked by alias); 15 Jul 2002 20:23:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22063 invoked from network); 15 Jul 2002 20:23:22 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 15 Jul 2002 20:23:22 -0000 Received: from dsl254-114-096.nyc1.dsl.speakeasy.net ([216.254.114.96] helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17UCNN-0005ea-00; Mon, 15 Jul 2002 15:23:21 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17UCNL-0004KV-00; Mon, 15 Jul 2002 16:23:19 -0400 Date: Mon, 15 Jul 2002 13:42:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/5.2/commit] Zap __func__ Message-ID: <20020715202319.GA16298@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3D32FB89.8030403@ges.redhat.com> <20020715175206.GA19809@nevyn.them.org> <3D332BFF.6030009@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D332BFF.6030009@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-07/txt/msg00341.txt.bz2 On Mon, Jul 15, 2002 at 04:09:35PM -0400, Andrew Cagney wrote: > >On Mon, Jul 15, 2002 at 12:42:49PM -0400, Andrew Cagney wrote: > > > >>Just FYI, > >> > >>I've committed this to the 5.2 branch - zap more __func__s. It's brutal > >>but it works :-) > >> > >>enjoy, > >>Andrew > > > > > >>2002-07-15 Andrew Cagney > >> > >> * dwarf2cfi.c: Replace __func__ with "?func?". > > > > > >Er, hunh? > > > >First of all, is there any reason that __FUNCTION__ is not adequately > >portable? I think it is. Second of all, if you're going to remove > >__func__ you could at least replace it with the name of the function. > > Remember this is a branch and those ``__func__''s were only printed when > there was an internal_error() - I don't think anyone is going to notice > :-). The correct clean fix was committed to the mainline a few hours > earlier (I looked at back patching it but noticed too many differences). - internal_error (__FILE__, __LINE__, - "%s: unknown register rule", __func__); + internal_error (__FILE__, __LINE__, "bad switch"); Is there any reason not to leave the error message as it was? It's just a matter of "update_context: unknown register rule". Replacing a clear internal error with "bad switch" doesn't seem like a good move. (having an internal_error here is a little shady anyway, it's like abort()ing on user input) > As for __FUNCTION__, that isn''t part of ISO C 90. Yep, you're right. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer