From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 565 invoked by alias); 7 Nov 2002 17:39:20 -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 557 invoked from network); 7 Nov 2002 17:39:20 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 7 Nov 2002 17:39:20 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 189sUs-0001VR-00; Thu, 07 Nov 2002 13:39:22 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 189qdP-0000Gj-00; Thu, 07 Nov 2002 12:40:03 -0500 Date: Thu, 07 Nov 2002 09:39:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: David Carlton , gdb-patches@sources.redhat.com, Jim Blandy , Fernando Nasser Subject: Re: [rfc] clean up linespec.c Message-ID: <20021107174003.GA872@nevyn.them.org> Mail-Followup-To: Elena Zannoni , David Carlton , gdb-patches@sources.redhat.com, Jim Blandy , Fernando Nasser References: <15818.41778.383411.897868@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15818.41778.383411.897868@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00178.txt.bz2 On Thu, Nov 07, 2002 at 12:30:26PM -0500, Elena Zannoni wrote: > > It turns out that decode_line_1 isn't quite as crazy a function as I'd > > feared. There's a reasonable flow of control underneath (well, at > > least there is once you get rid of the unnecessary goto's), though > > admittedly the C++ part of the function is still pretty complicated, > > and the function will always consist of a bunch of special cases. > > > > Having c++ separated in functions, is a first step in moving C++ > support to its own files.....:-) :) > > I hope I didn't break anything, though my only real evidence for that > > is that I didn't get any new regressions on the testsuite. (I have no > > idea how comprehensive the testsuite's coverage of linespec is.) > > ah, gcov data would be useful here... :-) Gcov data is good and all, but it's a required-but-not-sufficient for coverage testing. I've been doing some coverage tests on c-typeprint.c, and I would never have found the char *constvarname bug that was fixed recently. It's still impressively useful though :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer