Re: check_strxfrm_bug()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tristan Partin <tristan(at)neon(dot)tech>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: check_strxfrm_bug()
Date: 2023-07-06 16:20:26
Message-ID: 69795b94-7add-83d4-8264-1e5a23345709@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05.07.23 00:15, Thomas Munro wrote:
> On Tue, Jul 4, 2023 at 2:52 AM Tristan Partin <tristan(at)neon(dot)tech> wrote:
>> The patch looks good to me as well. Happy to rebase my other patch on
>> this one.
>
> Thanks. Here is a slightly tidier version. It passes on CI[1]
> including the optional extra MinGW64/Meson task, and the
> MinGW64/autoconf configure+build that is in the SanityCheck task.
> There are two questions I'm hoping to get feedback on: (1) I believe
> that defining HAVE_MBSTOWCS_L etc in win32_port.h is the best idea
> because that is also where we define mbstowcs_l() etc. Does that make
> sense? (2) IIRC, ye olde Solution.pm system might break if I were to
> completely remove HAVE_MBSTOWCS_L and HAVE_WCSTOMBS_L from Solution.pm
> (there must be a check somewhere that compares it with pg_config.h.in
> or something like that), but it would also break if I defined them as
> 1 there (macro redefinition).

I think the correct solution is to set HAVE_MBSTOWCS_L in Solution.pm.
Compare HAVE_FSEEKO, which is set in Solution.pm with fseeko being
defined in win32_port.h.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-07-06 16:38:03 Re: pg_basebackup check vs Windows file path limits
Previous Message Laurenz Albe 2023-07-06 16:15:56 Re: [PATCH] Add support function for containment operators