This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] plans for linespec.c
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: carlton at math dot stanford dot edu
- Cc: ezannoni at redhat dot com, fnasser at redhat dot com, gdb at sources dot redhat dot com, jimb at redhat dot com
- Date: Wed, 8 Jan 2003 22:24:08 -0600
- Subject: Re: [rfc] plans for linespec.c
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.
I know decode_line_1 does not touch symbol table implementation much
but the symbols that come in from the different symbol table readers
are quite, well, different. In fact I'd like to add coff or xcoff to
my own testing.
> (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!
Unfortunately it's very difficult psychologically to work on a piece
of code and then write test cases designed to break it.
Michael C