Hi Paul,
On Fri, Dec 11, 2009 at 3:20 PM, Paul Vriens paul.vriens.wine@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