From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3554 invoked by alias); 9 Jan 2003 06:01:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3507 invoked from network); 9 Jan 2003 06:01:28 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 9 Jan 2003 06:01:28 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h09614W15693; Wed, 8 Jan 2003 22:01:04 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Michael Elizabeth Chastain Cc: ezannoni@redhat.com, fnasser@redhat.com, gdb@sources.redhat.com, jimb@redhat.com Subject: Re: [rfc] plans for linespec.c References: <200301090424.h094O8224303@duracef.shout.net> From: David Carlton Date: Thu, 09 Jan 2003 06:01:00 -0000 In-Reply-To: <200301090424.h094O8224303@duracef.shout.net> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00118.txt.bz2 On Wed, 8 Jan 2003 22:24:08 -0600, Michael Elizabeth Chastain said: > Hi David, >> ... I'm not sure that your level of concern is warranted. My machine >> is old, so it would turn a 10-minute testing process into a 20-minute >> testing process; I'm happy to do that if you think it's important, >> but I'm not sure that it is in this particular instance. > It's kinda subjective. I tend to be conservative about these > things, and I tend not to think of testing as getting in the way of > my work flow (I like to proofread while the tests are running). So > it's not "you should I do this or I predict calamity" issue. If you > choose not to, I won't kick. If lots of new stabs+ regressions show > up then I will want it more. Fair enough. It's something I should get around to doing eventually for other reasons; maybe your nudging will move it up some. >> (I am, however, worried about problems that the test suite might not >> catch at all: it would be nice if somebody were to make sure that the >> testsuite systematically tested everything that decode_line_1 does. >> But that's another issue entirely.) > Grin. You are the expert on coverage cases for decode_line_1 now! There's actually an interesting question here as to whether or not I even can design coverage tests for the original version of decode_line_1: my only understanding of the function comes from decomposing it, so any tests that I'd design would be compromised by the assumption that I've preserved the behavior by that decomposition. Though, obviously, I'd be in a good position for designing coverage tests for the newer version. > Unfortunately it's very difficult psychologically to work on a piece > of code and then write test cases designed to break it. I'm trying to get better at writing test cases. My next task for my non-GDB programming project is to get a unit test system running, both for new code and for existing code, so hopefully test writing will get easier for me. Speaking of which, I had the thought that maybe we could do unit tests of some of the innards of GDB by writing separate test programs that we link with -lgdb. Something to think about. David Carlton carlton@math.stanford.edu