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

[Aaron Ballman]

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 "\\.\".

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.

>> +  // 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)?

Thanks!

~Aaron