[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