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

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

> Date: Wed, 4 May 2005 18:01:47 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
> 
> > No, it's not.  Given enough information, e.g., the leading directories
> > and the basename, one can reconstruct the absolute file name even if
> > it no longer exists.
> 
> All they take as an argument is a single filename.  If it doesn't
> exist, how can they add any value to that?

If cwd is /foo/bar and the file name passed to lrealpath is
"../abc/def", I can compute the absolute name /foo/abc/def even if
neither /foo/bar nor ../abc/def exist.

> > In any case, the fact that realpath fails for non-existent files does
> > not seem to be documented, and I, for one, would not necessarily
> > expect that, as some similar functions and system calls I've met over
> > the years on other platforms didn't fail like that.
> 
> Can you give me an example?  FYI, realpath in POSIX has this property,
> so I don't know what you mean by "not documented".

Sorry, too many similar names.  I meant that lrealpath does not
document that it fails for non-existent files.

> > Beware: you might break things by this change, since currently
> > lrealpath returns file names with backslashes, which is not a good
> > idea in a program that came from the Posix world.
> 
> GDB already handles pathnames with backslashes.  So does GCC.  So do
> the GNU binutils.  Those are the only programs I know of which use
> libiberty, and except for GDB they use lrealpath already.  The original
> implementation of lrealpath was based on gdb_realpath, FYI.  A Windows
> developer did the work to make things work properly when using
> GetFullPathName.

I replied to this in my other message: it's IMHO unsafe to return a
name with backslashes, becaues it might be passed to a program that
doesn't handle them well, like Bash or Make.