From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19514 invoked by alias); 4 May 2005 20:53:41 -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 19470 invoked from network); 4 May 2005 20:53:34 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 4 May 2005 20:53:34 -0000 Received: from zaretski (IGLD-80-230-9-69.inter.net.il [80.230.9.69]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id BDJ35225 (AUTH halo1); Wed, 4 May 2005 23:53:28 +0300 (IDT) Date: Wed, 04 May 2005 20:53:00 -0000 From: "Eli Zaretskii" To: gdb-patches@sources.redhat.com Message-ID: <01c550eb$Blat.v2.4$24b1dce0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050504183127.GA19094@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 4 May 2005 14:31:28 -0400) Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Reply-to: Eli Zaretskii References: <20050502195515.GA10429@nevyn.them.org> <01c54f57$Blat.v2.4$4c163500@zahav.net.il> <20050502204859.GA6090@nevyn.them.org> <01c54f91$Blat.v2.4$f6e0b160@zahav.net.il> <20050503034604.GA437@nevyn.them.org> <01c55017$Blat.v2.4$3cb51f20@zahav.net.il> <20050503194856.GA4477@nevyn.them.org> <01c55021$Blat.v2.4$520aa7a0@zahav.net.il> <20050504133437.GA10578@nevyn.them.org> <20050504183127.GA19094@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00139.txt.bz2 > Date: Wed, 4 May 2005 14:31:28 -0400 > From: Daniel Jacobowitz > Cc: gdb-patches@sources.redhat.com > > If we're returning a fullname at all, we've decided where to open the > file; we can share that decision with the user/client. That is perhaps true for openp, but not for xfullpath or gdb_realpath: those functions don't open the file, they just manipulate the string that is handed to them. > The question is what a front end can expect from GDB. The > documentation says it can expect an absolute path, not a > semi-absolute path. If the front end is going to open the file, it doesn't matter. If it is going to compare files for equality, it should not use string comparison, for the reasons I explained in another message. > You're very worked up about this. Because it took me quite an effort to make GDB DTRT with MS-style file names. So I don't want to see it go down the drain because of some test case. The main reason for these functions is to handle files which GDB needs to work with, not to display standardized names. That is, the ultimate test is whether opening the file will work or not, not if they look canonical. Canonicalization is a means, not an end in itself, except in the test that started this. So I'm willing to give up on this test, but not on what the code does, because I don't want us to break much more important situations where the current code works. > Of course, does it matter in practice? Does DJGPP support 'expect'? It doesn't. That's why I only care for the functions involved in this, not about the test case itself.