[llvm-commits] [llvm] r138213 - /llvm/trunk/lib/Support/Windows/PathV2.inc

[NAKAMURA Takumi]

2011/8/21 Aaron Ballman <aaron at aaronballman.com>:
> On Sun, Aug 21, 2011 at 9:09 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote:
>>> +  // First, check to see if this is a device namespace, which always
>>> +  // starts with \\.\, since device namespaces are not legal file paths.
>>> +  if (path.startswith("\\\\.\\"))
>>> +    return true;
>>
>> I am not sure, though, I am dubious "\\.\" would be handled here
>> and other methods in PathV2 would be aware of "\\.\".

I am sorry, I mistook and was confused "\\?\" and "\\.\" then.

> Yes, \\.\ is one of those path namespaces that you don't see too
> often.  But it does definitely signify a namespace that's not a file
> or folder in the traditional sense.  Since we're already looking for
> non-file devices like "con" and "com", supporting \\.\ seems logical
> to me.
>
> Whether other methods in PathV2 would need to be updated for \\.\,
> that's a good question.  I was using this more as a safeguard, in case
> it somehow snuck through.

Makes sense. Someday we should add namespace-aware tests to
unittests/Support/Path.

>>> +  // Then compare against the list of ancient reserved names
>>> +  for (size_t i = 0; i < sizeof(sReservedNames) / sizeof(const char *); ++i) {
>>> +    if (path.equals_lower(sReservedNames[i]))
>>> +      return true;
>>> +  }
>>
>> Nitpick: Shall we handle "x:\path\to\com9.txt" here?
>
> I could certainly add that.  Do we link against shlwapi.lib (available
> in Win2k and higher) so that I can use PathFindFileName?  Or should I
> prefer our filename function from PathV2.cpp (this one only worries me
> in case we accidentally run into infinite loops at some point)?

I think it would be enough to use PathV2 itself to parse path. Using
shell api might be overkill (and useless).
Note: "x:\path\to\com9.txt" is mapped to the device namespace.

Why NTOS does not provide us namespace mapping API? :/

...Takumi