Re: [RFA/commit] Improve gdb_realpath for Windows hosts

[Joel Brobecker <brobecker@adacore.com>]

> > gdb/ChangeLog:
> > 
> >         * utils.c (gdb_realpath): Add better support for Windows hosts.
> > 
> > Tested on x86-windows. Any objection to this?
> 
> Looks good to me.  Although there's a subtle semantic difference
> between `realpath' on Posix platforms and GetFullPathName: the former
> requires the file to exist, while the latter does not.  But I reckon
> we handle this somewhere...

Thanks for taking a look!

I was not aware of its behavior when the file does not exist.
It's strange, because MSN says:

    This function does not verify that the resulting path and file
    name are valid, or that they see an existing file on the associated
    volume.

It's ambiguous, and you're probably right. But it explains
my surprise.

That being said, it's treated as a normalization error, and
we fallback to xstrdup in that case, hoping that the user then
uses the a filename that matches according to filename_cmp
(it deals with casing and directory separators, but not the
case of consecutive directory separators). In other words,
if the file does not exist, we're back to where we were before
this patch.

> Did you test this with UNC file names?

I did not test with UNC file names, no. Mostly because it never
entered my mind. I'm not a Windows person I'm afraid, never used it
unless asked to fix a bug that reproduces on this system only. And
I don't know if this is something I could do with our machines at
work.

That being said, MSDN does confirm that it should work (I think!):

    Share and volume names are valid input for lpFileName. For example,
    the following list identities the returned path and file names if
    test-2 is a remote computer [...]:

        # If you specify "\\test-2\q$\lh" the path returned is
          "\\test-2\q$\lh"

        # If you specify "\\?\UNC\test-2\q$\lh" the path returned is
          "\\?\UNC\test-2\q$\lh"

-- 
Joel