From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3727 invoked by alias); 7 Nov 2002 17:45: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 3697 invoked from network); 7 Nov 2002 17:45:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Nov 2002 17:45:17 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gA7HMYw20755 for ; Thu, 7 Nov 2002 12:22:34 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA7HjGf01800; Thu, 7 Nov 2002 12:45:16 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA7HjET25931; Thu, 7 Nov 2002 12:45:14 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 71506FF79; Thu, 7 Nov 2002 12:41:07 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15818.42419.4927.908878@localhost.redhat.com> Date: Thu, 07 Nov 2002 09:45:00 -0000 To: Daniel Jacobowitz Cc: Elena Zannoni , David Carlton , gdb-patches@sources.redhat.com, Jim Blandy , Fernando Nasser Subject: Re: [rfc] clean up linespec.c In-Reply-To: <20021107174003.GA872@nevyn.them.org> References: <15818.41778.383411.897868@localhost.redhat.com> <20021107174003.GA872@nevyn.them.org> X-SW-Source: 2002-11/txt/msg00179.txt.bz2 Daniel Jacobowitz writes: > 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. > Yeah, also things get complicated because gdb has so many different targets that trigger so many different code paths, that you are never sure if some code is really never covered. > It's still impressively useful though :) > true. Elena > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer