[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
>
Cheers,
Rafael
More information about the cfe-commits
mailing list