Hi,
On 05/18/17 17:46, Stefan Dösinger wrote:
Am 2017-05-18 um 14:35 schrieb Piotr Caban:
Could you please check if there really is such a length limit in wchar version of the function?
I'm working on it. What is the deal with wchar_t vs WCHAR in the implementation vs the tests?
It can probably use some cleanup :)
Also I am not sure the existing test establishes the -3 for the A version. I'll extend it if my reading is right.
WideCharToMultiByte(CP_ACP, 0, target_w, -1, target, wcslen(target_w) + 1, NULL, NULL);You can use MAX_PATH here instead of wcslen(target_w)+1.
I guess the app is required to pass a pointer to a string that's at least MAX_PATH in size because there is no way to communicate the length. Given that constraint it should be safe to convert MAX_PATH chars.
However, with the actual implementation an app could get away with a shorter array if the actual path is shorter I think, and the app may be able to know the length in advance. So blindly converting MAX_PATH characters could cause a problem.
There's no change in function behavior if MAX_PATH is passed to WideCharToMultiByte here. This argument means that at most MAX_PATH characters will be written to target buffer. It will still work if application passes smaller buffer.
The application is actually required to pass a MAX_PATH buffer to tr2_sys__Open_dir function. Demangled function signature is following: void * __cdecl std::tr2::sys::_Open_dir(char (&)[260],char const *,int &,enum std::tr2::sys::file_type &) (of course application can ignore this restriction with a simple cast)
Thanks, Piotr