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

  1. Don't expose Windows' mbstowcs_l() and wcstombs_l().

  2. All supported systems have locale_t.

  3. Remove obsolete defense against strxfrm() bugs.