Noah Misch писал(а) 2024-12-17 02:16:
I wasn't ready to believe it, but 010_dump_connstr indeed fails with
GetACP()==932. We've had test coverage of this for 8+ years, so I
gather few
or no runs of the TAP suite on GetACP()==932 systems have ever
happened. Wow.
Here's how your particular example traverses the CP932 command line:
CreateProcessA(0xe6 0x96 0x87 0xe5 0xad 0x97 0xe5 0x8c 0x96 0xe3 0x81
0x91)
argv[1] = e6 96 81 45 ad 97 e5 8c 96 e3 81
GetCommandLineA() = 61 20 e6 96 81 45 ad 97 e5 8c 96 e3 81
GetCommandLineW() = 61 20 8b41 30fb ff6d 601c 55a7 7e3a
It's a shame the implicit conversion here doesn't fail with EILSEQ. I
can't imagine how anything good can ever have come from lossy,
non-error-raising implicit conversions anywhere near argv[]. On the
It's a shame.
I also found that 010_dump_connstr fails, if Windows has UTF-8 option on
(in language setting,
mentioned as beta feature in option description).
It looks like this test does not consider language settings. It creates
user with a long name,
language settings can increase this name by 2 times in UTF-8 case,
Postgres cut this name to 64 bytes, but the test continues to use
original long name and fails.
It is not clear, what exactly the test checks, if it fails before the
dump check.
--
Best regards,
Vladlen Popolitov.
