This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch/rfc] KFAIL gdb.c++/annota2.exp watch triggered on a.x

On Fri, 3 Jan 2003 16:12:26 -0600, Michael Elizabeth Chastain <> said:

> One advantage of David's code is that when the bug gets fixed,
> people see a more informative message for a while: "KPASS gdb/38"
> rather than "PASS".

Actually, I don't consider that an advantage at all: any KPASS seems
to me to demand an investigation, and should be eradicated.  So, when
somebody fixes this bug, I think that somebody should change the
KPASSes to plain old normal PASSes.  (As well as remove or comment out
the KFAIL branches, as I said in my response to Daniel that crossed
your e-mail.)

Basically, I see three different priorites of output messages (I'm
ignoring ERROR/UNSUPPORTED/etc. for now):

1) PASS: everything is peachy keen.

2) KFAIL/XFAIL: something doesn't work right, but at least we know
   that it doesn't work right.

3) FAIL/KPASS/XPASS: either something doesn't work right that we
   weren't aware of, or something does work right when we think it

And, in the mythical utopia where the GDB testsuite has been carefully
audited to have KFAILs added where appropriate, messages in category 3
are grounds for immediate investigation, whereas messages in
categories 1 and 2 aren't grounds for immediate investigation.

So, when bugs have been fixed, I don't want to see KPASS (because that
gives the misleading impression that we think it hasn't been fixed) or
KFAIL (because that gives the misleading impression that we're aware
that the bug hasn't, in fact, been fixed after all).

David Carlton

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]