[PATCH 3/3] mpr: Implement WNetUseConnectionA(). (try 4)

[Pierre Schweitzer]

On 22/01/2016 09:58, Alexandre Julliard wrote:
> Pierre Schweitzer <pierre at reactos.org> writes:
> 
>> +    ret = WNetUseConnectionW(hwndOwner, pRes, passW, userIDW, dwFlags,
>> +                             accessNameW, lpBufferSize, lpResult);
>> +    if (lpAccessName && lpBufferSize && *lpBufferSize && accessNameW)
>> +    {
>> +        len = WideCharToMultiByte(CP_ACP, 0, accessNameW, -1, NULL, 0, NULL, NULL);
>> +        if (len && len <= *lpBufferSize)
>> +            WideCharToMultiByte(CP_ACP, 0, accessNameW, -1, lpAccessName, len, NULL, NULL);
>> +    }
> 
> You need to handle failures, and a possibly different lpBufferSize for
> the W function. It could also use some test cases, which would probably
> require the W function to do something useful first.

Thanks for your review.

There's no need, in my understanding of MSDN of a different
lpBufferSize. It contains the size in chars of the buffer. So, be it for
A or W, we pass the same, and if W function fails because of a too
limited amount of chars available, that's the value we have to return to
caller, so there's no need, in my view, to create an extra indirection.
If you have another understanding, please share.

Regarding the W function, I only have a really specific implementation
[1], designed to allow VBox Shared Folders provider to work (which it
does perfectly), but it clearly doesn't match the quality standards of
Wine and thus, I cannot propose it to Wine. When I come to a more
correct implementation, I'll come to Wine with it and with tests.

[1]: https://jira.reactos.org/browse/CORE-10032

Cheers,
-- 
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3960 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160123/48d49bb2/attachment.bin>