Re: check_strxfrm_bug()
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Thomas Munro <thomas.munro@gmail.com>
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-10T14:28:40Z
Lists: pgsql-hackers
On 10.07.23 04:51, Thomas Munro wrote: > On Sun, Jul 9, 2023 at 6:35 PM Thomas Munro <thomas.munro@gmail.com> wrote: >> 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. > > Thinking about that some more... Its _XXX implementations don't deal > with UTF-8 the way Unix-based developers would expect, and are > therefore just portability hazards, aren't they? What would we gain > by restoring the advertisement that they are available? Perhaps we > should go the other way completely and remove the relevant #defines > from win32_port.h, and fully confine knowledge of them to pg_locale.c? > It knows how to deal with that. Here is a patch trying this idea > out, with as slightly longer explanation. This looks sensible to me. If we ever need mbstowcs_l() etc. outside of pg_locale.c, then the proper way would be to make a mbstowcs_l.c file in src/port/. But I like your approach for now because it moves us more firmly into the direction of having it contained in pg_locale.c, instead of having some knowledge global and some local.
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