From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2942 invoked by alias); 8 Apr 2002 15:19:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1534 invoked from network); 8 Apr 2002 15:19:43 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 8 Apr 2002 15:19:43 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16uavf-0006l4-00; Mon, 08 Apr 2002 11:19:35 -0400 Date: Mon, 08 Apr 2002 08:19:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] gdb.c++/method.exp Message-ID: <20020408111935.A25907@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <200204081512.g38FCkt17254@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200204081512.g38FCkt17254@duracef.shout.net> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00296.txt.bz2 On Mon, Apr 08, 2002 at 10:12:46AM -0500, Michael Elizabeth Chastain wrote: > Good morning Daniel, > > Erm... did we reach a conclusion about whether those const's were > > really optional? In a const method, there should be a const on the > > type of 'this'. > > The old script accepted these strings: > > // non-const method > "A *" => PASS > default => FAIL > > // const method, gcc_compiled=TRUE > "A *" => PASS > "const class A *" => XFAIL > default => FAIL > > // const method, gcc_compiled=FALSE > "const class A *" => PASS > "A *" => XFAIL > default => FAIL > > // non-const method > "funk *" => PASS > default => FAIL > > One problem is that none of the tests accepted the second "const" > after the "*". Another problem, obviously, is the weird logic > for const methods that depends on gcc_compiled, and *rejects* > "const A *" for const methods when gcc_compiled=TRUE. > > The new script accepts these strings: > > // non-const method > "class A * const" => PASS > "class A *" => PASS > "A * const" => PASS > "A *" => PASS > default => FAIL > > // const method > "const class A * const" => PASS > "const class A *" => PASS > "const A * const" => PASS > "const A *" => PASS > "class A * const" => PASS > "class A *" => PASS > "A * const" => PASS > "A *" => PASS > default => FAIL > > // non-const method > "class A * const" => PASS > "class A *" => PASS > "A * const" => PASS > "A *" => PASS > default => FAIL > > So the old script reported FAIL to "const A *" for a constant method > when the compiler is gcc. The new script reports PASS. That's a > definite improvement. Yes, it is! > The old script reported PASS to "A *" for a constant method when the > compiler is gcc. That is problematic. Right now the new script also > reports PASS, to be compatible with the old script. > > Now is a good time to break compatibility anyways. The new script looks > like this right now (for a const method): > > gdb_test "print this" \ > "\\$\[0-9\]* = \\((const |)(class |)A *\\* *(const|)\\) $hex" \ > "print this in A::bar" > > What do you think of this: > > gdb_test "print this" \ > "\\$\[0-9\]* = \\(const (class |)A *\\* *(const|)\\) $hex" \ > "print this in A::bar" I think this is right. That will cause failures for 2.95/stabs and 3.0/stabs; we can XFAIL appropriately (based on version numbers even!). Does anything currently produce A const * const? It's probably legal... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer