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.
