Hi,
In the course of investigating why patch 169366 fails on test VMs with locales, I found out a possible bug or quirk in Wine's implementation of CP_UNIXCP.
Since this code page is not found on Windows, I cannot know what is "correct" behavior here.
So, WideCharToMultiByte(CP_UNIXCP, ...) with a locale doesn't seem to use CP_UTF8, but instead uses unix_cptable.
The problem seems to be in the fact that the 'used' parameter is *never* set in this case. It passes 'used ? &used_tmp : NULL' and then breaks out of the switch -- and the 'if (used) *used = used_tmp;' statement only applies in the default case of the switch. So I'm basically using an uninitialized variable.
Is this intended, or a bug?
What should I do then for patch 169365? Should I simply use CP_UTF8 or ignore the 'used' parameter?
Or perhaps fix this bug and set the 'used' parameter properly for CP_UNIXCP in the implementation of WideCharToMultiByte? Is there a reason it is even using used_tmp in the first place?
Thanks, Gabriel
Gabriel Ivăncescu gabrielopcode@gmail.com writes:
The problem seems to be in the fact that the 'used' parameter is *never* set in this case. It passes 'used ? &used_tmp : NULL' and then breaks out of the switch -- and the 'if (used) *used = used_tmp;' statement only applies in the default case of the switch. So I'm basically using an uninitialized variable.
Is this intended, or a bug?
It's a bug, thanks for catching it.
On 9/4/19 5:32 PM, Alexandre Julliard wrote:
Gabriel Ivăncescu gabrielopcode@gmail.com writes:
The problem seems to be in the fact that the 'used' parameter is *never* set in this case. It passes 'used ? &used_tmp : NULL' and then breaks out of the switch -- and the 'if (used) *used = used_tmp;' statement only applies in the default case of the switch. So I'm basically using an uninitialized variable.
Is this intended, or a bug?
It's a bug, thanks for catching it.
I've sent some patches to fix this and simplify CP_UNIXCP for callers.
-
Alexandre Julliard -
Gabriel Ivăncescu