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

[NAKAMURA Takumi]

Aaron,

2011/8/24 Aaron Ballman <aaron at aaronballman.com>:
>>>> 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.
>
> I've attached a patch to address this so that we now use the path
> "stem" to do the comparison.  This means we'll catch DOS device names
> like "com9" as well as ill-named compete paths like
> x:\path\to\com9.txt.

I am sorry, it must be too bikeshed for us.
Usually, it would be enough for us to detect *intentional* device
names. (eg. "nul")
I rethought maniac detection would be overkill here.

FYI, "X:/existent/path/to/nul.blahblah/nonexistent/path/to" is mapped
to device namespace.
"X:/nonexistent/path/to/nul.blahblah" is not.

In common cases, such a weird device names could raise error in
somewhere, I expect.

> Additionally, I addressed your suggestion about the static declaration
> using array notation instead of pointer notation.  However, I'd be
> curious to hear why you have this preference (you could email me
> off-list if you'd prefer).

char const *foo[] = {"qux", "quux"}; It spends two R/W(.data)
pointers(4 or 8 bytes per an element) and two literal constant(4 bytes
and 5 bytes).
(note, it is more possible "char const *const foo[] = ...", then
pointers are allocated to .rodata)

In contrast, char const foo[][5] = {'qux", "quux"}; It only spends 10
bytes of constant array.

Yeah, I know it might be still my preference, thank you dou itashimashite!

...Takumi