3 ms·
Decades of binaries are in use doing something like ``` wchar_t filename[MAX_PATH]; CreateFileW(...) ``` in both first part and third party Windows code, ofte
by Arainach 3y ago
Decades of binaries are in use doing something like
```
wchar_t filename[MAX_PATH];
CreateFileW(...)
```
in both first part and third party Windows code, often in deep callstacks passing file names around. Changing the length requires fixing them all.
See comments in https://archives.miloush.net/michkap/archive/2006/12/13/1275292.html https://archives.miloush.net/michkap/archive/2006/12/13/1275...
- TonyTrapp 3y agoYour example isn't problematic API-wise, because CreateFileW doesn't need to care if you pass in 16 characters or 1600 - if it does, that is mostly a matter of refactoring and not inherent to how the function works. The real problem are APIs that inherently assume that you pass in a string of at most MAX_PATH characters, because you provide a pointer but no size, and the API is expected to write to that pointer. This affects most shell32 getter functions, e.g. SHGetKnownFolderPath. But for functions outside of Windows itself, this is the exact reason why the long path feature is hidden behind an opt-in flag.