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

[Bob Rossi <bob at brasko dot net>]

On Mon, May 02, 2005 at 04:49:00PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 02, 2005 at 11:40:18PM +0300, Eli Zaretskii wrote:
> > > Date: Mon, 2 May 2005 15:55:15 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: gdb-patches@sources.redhat.com
> > > 
> > > The usual definition of absolute is that it doesn't rely on current
> > > state to resolve it.
> > 
> > DOS/Windows file names can be gray, not only white or black.  Examples
> > include \abc and d:foo.  While not entirely free of ``current''
> > something, they are much closer to absolute file names than to
> > relative file names, in the sense that you don't prepend cwd to them
> > to get an absolute file name (which is what 99.99% of programs
> > _really_ want to know when they are testing a file name for being
> > absolute).
> 
> That's not what we're testing for in the testsuite, though.  I think
> that we should reject both \abc and d:foo here.  We're trying to output
> a full pathname.

The question is, will GDB will return \abc or d:foo from source.c:openp?
I see that IS_ABSOLUTE_PATH is being used, which specifically says it
allows the case \abc and d:foo. 

So, the next question is, does xfullpath change \abc or d:foo into a 
real absolute path or not?

Notice the comment in utils.c:3021

#ifdef HAVE_DOS_BASED_FILE_SYSTEM
  /* We need to be careful when filename is of the form 'd:foo', which
     is equivalent of d:./foo, which is totally different from d:/foo.  */
  if (strlen (dir_name) == 2 && isalpha (dir_name[0]) && dir_name[1] == ':')
    {
      dir_name[2] = '.';
      dir_name[3] = '\000';
    }
#endif

That above comment broke my brain :)

Thanks,
Bob Rossi