From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21945 invoked by alias); 3 Jan 2003 22:53:13 -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 21938 invoked from network); 3 Jan 2003 22:53:12 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 3 Jan 2003 22:53:12 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h03Mr0i31864; Fri, 3 Jan 2003 14:53:00 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb Cc: Michael Elizabeth Chastain , Daniel Jacobowitz Subject: [rfc] xfailed tests in gdb.c++/classes.exp From: David Carlton Date: Fri, 03 Jan 2003 22:53:00 -0000 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/msg00037.txt.bz2 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