[PATCH] Fixing a driver bug where clang cannot locate source file at drive root

Rafael Espíndola rafael.espindola at gmail.com
Mon Jul 29 12:22:47 PDT 2013

On 29 July 2013 14:58, Arthur O'Dwyer <arthur.j.odwyer at gmail.com> wrote:
> Rafael,
>   Is this wacky behavior a Cygwin bug, or did Microsoft's actual
> behavior change sometime between Win95 and Win7, or was there a flaw
> in your experiment?  The usual meaning of "C:foo.c" is
> * C:\<last working directory on C:>\foo.c    if the current volume *is
> not* C:; or
> * .\foo.c      if the current volume *is* C:.
> I suspect that what everyone is really looking for is just the Windows
> API function GetFullPathName(), although its documentation isn't very
> clear about its behavior on "C:foo.c" and unfortunately I'm not in a
> position to test it.  There doesn't seem to be any documented way to
> extract the "last working directory on C:" information from the
> Windows API without also changing the working directory.  But if
> that's acceptable, then there's this:
>     TCHAR buffer[64000];
>     SetCurrentDirectory("C:");
>     GetCurrentDirectory(buffer, 64000);  // I suspect this yields
> "C:\<last working directory on C:>\"

That is correct, thanks!

I tested it with cl.exe in a native windows shell. If I switch to D:
without cding to c:\, then C:foo.c corresponds to C:\<the last
directory in C>\foo.c.

looks like this is used in clang only for caching, so maybe in the end
the best would be for parent_path to return an empty string ref for
"C:foo.c" as a way of signaling "I don't know" and clang can just not
cache that.

> HTH,
> –Arthur


More information about the cfe-commits mailing list