[PATCH 1/3] msvcp: Implement the wchar version of _Open_dir.
Piotr Caban
piotr.caban at gmail.com
Fri May 19 04:01:02 CDT 2017
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
More information about the wine-devel
mailing list