Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: [rfc] xfailed tests in gdb.c++/classes.exp
@ 2003-01-03 23:27 Michael Elizabeth Chastain
  0 siblings, 0 replies; 10+ messages in thread
From: Michael Elizabeth Chastain @ 2003-01-03 23:27 UTC (permalink / raw)
  To: carlton, gdb; +Cc: drow

> 1) GDB prints "class X { public: ... }" when the programmer originally
>    wrote "struct X { ... }".

We talked about this about two years ago, and the consensus was
that this is a bug in gdb.  I did not agree with that consensus.

> 2) GDB prints "class X { private: int x; ... }" when the programmer
>    originally wrote "class X { int x; ... }".

I don't recall discussing this in particular.

> The arguments for treating them as passes is as follows: GDB's goal
> isn't to print out exactly what the programmer typed: it's to print
> out a type that's equivalent to what the programmer typed, one that
> gives all the information that the programmer needs.

I believe in this.

> And, in both of the cases above, programmers could replace their
> definitions by the definitions that GDB prints out without changing the
> behavior of their programs.

I believe this is a good operational test.

As a user, it's perfectly fine with me that GDB canonicalizes the
class/struct when printing it out.  It's vital that GDB prints
_correct_ information.  It's important that GDB prints _complete_
information.  We have so many problems at this level with C++,
it's a crying shame that we devote bug-handling resources to
"class X { public: ... }".

> Personally, I'd treat both these cases as passes.  On the other hand,
> Daniel's the C++ maintainer; if he thinks one or both of these cases
> should be considered a bug in GDB, then I'll file PR's and KFAIL them
> as appropriate.

Ditto.

Michael C


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [rfc] xfailed tests in gdb.c++/classes.exp
@ 2003-02-28  5:01 Michael Elizabeth Chastain
  2003-02-28 15:15 ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: Michael Elizabeth Chastain @ 2003-02-28  5:01 UTC (permalink / raw)
  To: drow, gdb

> Sure.  But I suspect 2) represents an actual bug.  Fixing this is about
> three lines in c-typeprint.c.  Should we or shouldn't we?

A little late night rambling ...

It depends on your role.

In the QA role I've got kind of a black-boxy view.  If the test script
mimics what a user would type, and if I think that most users would be
happy, then I'm happy.

In the developer role, any loose edge might be a symptom of a bug.  I
remember when one little test in selftest.exp did not pass and I traced
it down to memory corruption inside gdb.  And we all know that a stitch
in time saves nine.  If you're looking at results that don't match what
you, as a developer, believe the code should do, that is noteworthy,
even if Joe User has no issue with it.

Also, gdb has thousands more problems than we can fix.  We have to do
brutal triage on our TODO lists, every day.  And I am personally bad at
prioritizing.  In fact one of my motives for working on gdb is to
practice better prioritizing in an environment that lets me set my own
goals.

Michael C


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [rfc] xfailed tests in gdb.c++/classes.exp
@ 2003-02-28  3:51 Michael Elizabeth Chastain
  2003-02-28  3:59 ` Daniel Jacobowitz
  2003-02-28 20:58 ` Jason Molenda
  0 siblings, 2 replies; 10+ messages in thread
From: Michael Elizabeth Chastain @ 2003-02-28  3:51 UTC (permalink / raw)
  To: carlton, drow; +Cc: gdb

dc> 1) GDB prints "class X { public: ... }" when the programmer originally
dc>    wrote "struct X { ... }".

I think this should be a PASS.

dc> 2) GDB prints "class X { private: int x; ... }" when the programmer
dc>    originally wrote "class X { int x; ... }".

I think this should be a PASS.

David C formulated this idea as: if the text can be fed back into a C++
compiler and generate the same results, then it's okay.  By and large I
agree with that.

If you look in gnats, you will see users complaining that they can't
print their string variables (because C++ strings are implemented with
layers of templates and derived classes).  They are complaining that
operator overloading doesn't work.  They are complaining that they have
a std::vector<Foo> and they can't even look inside the damn thing.

They aren't complaining that they wrote 'struct X { ... }' but gdb
prints 'class X { public: ... }'.

Michael C


^ permalink raw reply	[flat|nested] 10+ messages in thread
* [rfc] xfailed tests in gdb.c++/classes.exp
@ 2003-01-03 22:53 David Carlton
  2003-02-28  1:30 ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: David Carlton @ 2003-01-03 22:53 UTC (permalink / raw)
  To: gdb; +Cc: Michael Elizabeth Chastain, Daniel Jacobowitz

I've been looking at the xfailed tests in gdb.c++/classes.exp, and
some of the xfails aren't too convincing.  Specifically, the tests
that I'm looking at do ptypes of C++ data structures, and several of
the xfails fall into one or both of these categories:

1) GDB prints "class X { public: ... }" when the programmer originally
   wrote "struct X { ... }".

2) GDB prints "class X { private: int x; ... }" when the programmer
   originally wrote "class X { int x; ... }".

My question is: should we consider these as GDB bugs, or not?  In
other words, should I change the xfails to kfails, or should I change
them to passes?

The arguments for treating them as passes is as follows: GDB's goal
isn't to print out exactly what the programmer typed: it's to print
out a type that's equivalent to what the programmer typed, one that
gives all the information that the programmer needs.  So it would be
ridiculous, for example, to call it a bug in GDB if GDB didn't exactly
replicate the whitespace in a definition.  And, in both of the cases
above, programmers could replace their definitions by the definitions
that GDB prints out without changing the behavior of their programs.
Stroustrup says: "By definition, a struct is a class in which members
are by default public"; and just because members of a class are, by
default, private doesn't mean that there's anything wrong with making
that default explicit.

The arguments for treating them as failures are that DWARF 2 does, in
fact, contain enough information to be able to recover the data that
we're ignoring.  (GCC doesn't emit it, at least in case 1, but never
mind that.)  And, while changing all instances of "struct X { ... }"
to "class X { public: ... }" is behavior-preserving, changing one
instance might violate the one definition rule, so the two versions
aren't really the same for sufficiently pedantic definitions of "the
same".

Personally, I'd treat both these cases as passes.  On the other hand,
Daniel's the C++ maintainer; if he thinks one or both of these cases
should be considered a bug in GDB, then I'll file PR's and KFAIL them
as appropriate.

Opinions?

David Carlton
carlton@math.stanford.edu


^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-02-28 20:58 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-03 23:27 [rfc] xfailed tests in gdb.c++/classes.exp Michael Elizabeth Chastain
  -- strict thread matches above, loose matches on Subject: below --
2003-02-28  5:01 Michael Elizabeth Chastain
2003-02-28 15:15 ` Daniel Jacobowitz
2003-02-28 17:58   ` David Carlton
2003-02-28  3:51 Michael Elizabeth Chastain
2003-02-28  3:59 ` Daniel Jacobowitz
2003-02-28 13:40   ` Paul Koning
2003-02-28 20:58 ` Jason Molenda
2003-01-03 22:53 David Carlton
2003-02-28  1:30 ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox