UNC Pathname handling

[Alexandre Hardy]

Hi Paul,

On Fri, Dec 11, 2009 at 3:20 PM, Paul Vriens <paul.vriens.wine at gmail.com> wrote:
>> +    if (!(tmplongpath = (WCHAR *)HeapAlloc( GetProcessHeap(), 0,
>> MAX_LONGPATHNAME_LEN * sizeof(WCHAR) ))) {
>> +        SetLastError( ERROR_OUTOFMEMORY );
>> +        return 0;
>> +    }
>> +
>
> This is not really dynamic, is it? You are still allocating that same
> amount. Now, I'm not sure how to fix this as you need some way of
> calculating the needed length in any case. Is that cast necessary btw?

It is not the same amount of memory allocated as previously. Before it
was somewhere
in the order of 255 WCHARS, now it is 32767 WCHARS. Although I can allocate
this statically, I am a little concerned that there may be too much pressure
on the available stack space. Not sure about this though. The value can't
really be determined dynamically, I need enough memory to store whatever
path may be returned. (Similar to GetLongPathNameA).

>
> Now as I understand the function it can only be a maximum of 32767 when you
> use '\\?\', right? If so then this allocation should only be needed in the
> '\\?\' case. This however is something you have to add tests for as well. So
> create a path > MAX_PATH (if that's possible as I guess the path/file has to
> exist as well) and see what is returned on Windows.
Actually, I'm not certain that the maximum is not always 32767 WCHARS.
The MSDN states that GetLongPathNameA is limited to MAX_PATH characters,
and that you should use "\\?\" to increase the limit to 32767 characters.
I'm not entirely sure what GetLongPathNameW has as a limit.

>
> As you are now covering the '\\?\' case the ERR should go down as well and
> should maybe be a FIXME now?
Share names are still not covered. So it is a slite improvement for UNC
pathnames, but not a complete improvement. I'll follow your
guidelines on this point.

Kind regards
Alexandre


-- 
--------------------------------------------------
Alexandre Hardy
http://www.ahardy.za.net