Re: [RFC] fullname attribute for GDB/MI stack frames

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Wed, 4 May 2005 14:31:28 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 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.