Re: check_strxfrm_bug()
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Tristan Partin <tristan@neon.tech>, Noah Misch <noah@leadboat.com>, Heikki Linnakangas <hlinnaka@iki.fi>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-07-09T06:35:39Z
Lists: pgsql-hackers
On Sun, Jul 9, 2023 at 6:20 PM Peter Eisentraut <peter@eisentraut.org> wrote: > So I don't think this code is correct. AFAICT, there is nothing right > now that can possibly define HAVE_MBSTOWCS_L on Windows/MSVC. Was that > the intention? Yes, that was my intention. Windows actually doesn't have them. The autoconf/MinGW test result was telling the truth. Somehow I had to make the three build systems agree on this. Either by strong-arming all three of them to emit a hard-coded claim that it does, or by removing the test that produces a different answer in different build systems. I will happily do it the other way if you insist, which would involve restoring the meson.build and Solultion.pm kludges you quoted, but I'd also have to add a compatible kludge to configure.ac. It doesn't seem like an improvement to me but I don't feel strongly about it. In the end, Solution.pm and configure.ac will be vaporised by lasers, so we'll be left with 0 or 1 special cases. I don't care much, but I like 0, it's nice and round.
Commits
-
Don't expose Windows' mbstowcs_l() and wcstombs_l().
- 4e9fa6d56b3e 17.0 landed
-
All supported systems have locale_t.
- 8d9a9f034e92 17.0 landed
-
Remove obsolete defense against strxfrm() bugs.
- 7d3d72b55edd 16.0 landed