[PATCH 1/4] msvcrt/tests: Restore the multibyte codepage after the tests.

[Akihiro Sagawa]

N.B. _setmbcp() doesn't return the previous codepage.

Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com>
---
 dlls/msvcrt/tests/string.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

[Piotr Caban]

Hi Akihiro,

It looks like you're working around a bug in setlocale implementation. 
Is mbcp ever changed on Windows during this tests (it's not on testbot)? 
It's better to add a test for that and fix the implementation.

Thanks,
Piotr

[Akihiro Sagawa]

On Thu, 29 Aug 2019 17:05:37 +0200, Piotr Caban wrote:
> Hi Akihiro,
>
> It looks like you're working around a bug in setlocale implementation.
> Is mbcp ever changed on Windows during this tests (it's not on testbot)?
> It's better to add a test for that and fix the implementation.

Hi Piotr,

I put several traces in the test. Could you take a look this test result?
https://testbot.winehq.org/JobDetails.pl?Key=56064&f208=exe32.report#k208

The test ran on Windows 7 in Japanese codepage. Yes, mbcp is changed
from 932 to 0 between L2716 (at the beginning of test_wctob function)
and L2746 (at the end of the function).

setlocale() doesn't update mbcp. This is msvcrt feature. See L380 and
L384. Before L380, mbcp is 936 by _setmbcp() at L257. If setlocale() at
L380 affects mbcp, _mbccpy() at L384 copies the whole string because
it's neutral "C" locale. But, it copies only two bytes because the next
byte of the string is an invalid multibyte sequence. In other words,
mbcp is still in effect after setlocale().

The above test (L384) passes in native and Wine. So, Wine's setlocale()
implementation has no problems at this point.

Thanks for reviewing,
Akihiro Sagawa