From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23343 invoked by alias); 16 Jan 2007 22:16:31 -0000 Received: (qmail 23331 invoked by uid 22791); 16 Jan 2007 22:16:30 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Jan 2007 22:16:25 +0000 Received: from kahikatea.snap.net.nz (unknown [123.255.62.204]) by viper.snap.net.nz (Postfix) with ESMTP id 2F9083D82D9; Wed, 17 Jan 2007 11:16:22 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 5C1344F711; Wed, 17 Jan 2007 11:16:20 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17837.18315.809868.354650@kahikatea.snap.net.nz> Date: Tue, 16 Jan 2007 22:16:00 -0000 To: Mark Kettenis Cc: ghost@cs.msu.su, gdb-patches@sources.redhat.com Subject: Re: MI failures related to string printing In-Reply-To: <200701162123.l0GLN5kF029500@brahms.sibelius.xs4all.nl> References: <200701121351.29310.vladimir@codesourcery.com> <17831.31430.442855.801431@kahikatea.snap.net.nz> <17836.26533.146945.793792@kahikatea.snap.net.nz> <200701162123.l0GLN5kF029500@brahms.sibelius.xs4all.nl> X-Mailer: VM 7.19 under Emacs 22.0.92.10 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00368.txt.bz2 > > If your just talking about the one FAIL in mi-var-child.exp, why not > > just mark it as an XFAIL? I see that the other XFAIL actually > > passes (for me, at least). > > The very fact that we're even having this discussion means that you > did something wrong Nick; you either didn't check for regressions or > ignored them. Neither, it doesn't fail for me. Presumably this has something to do with the compiler/OS and where the variable values are stored. > Turning a regression test from a PASS into a FAIL, means you've > changed behaviour. Now that change could be intentional, but then you > should have said so when you submitted the patch, and you should have > adjusted the test. The nature of the patch was discussed at length and if there was no change in behaviour then the patch would be pointless. If the test had failed for me, I would have tried to adjust it. When is it appropriate to use an XFAIL, if not here? > I'm still not convinced the change is ok. Having 'char *' point to a > buffer that's not null-terminated is not uncommon. We have a lot of > those in gdb itself. There's still time to revert it but I think we should identify a real situation i.e when GDB is used with a frontend, where it causes a problem first. -- Nick http://www.inet.net.nz/~nickrob