This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] fullname attribute for GDB/MI stack frames
> 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.