Re: check_strxfrm_bug()

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tristan Partin <tristan(at)neon(dot)tech>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-07 22:13:21
Message-ID: CA+hUKGJcbMFc7nXeJW1nWZnvd=j+xMpZLXADHbc91cT1NpT_sw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 8, 2023 at 8:52 AM Tristan Partin <tristan(at)neon(dot)tech> wrote:
> Should you wrap the two _l function replacements in HAVE_USELOCALE
> instead of WIN32?

I find that more confusing, and I'm also not sure if HAVE_USELOCALE is
even going to survive (based on your nearby thread). I mean, by the
usual criteria that we applied to a lot of other system library
functions in the 16 cycle, I'd drop it. It's in the standard and all
relevant systems have it except Windows which we have to handle with
special pain-in-the-neck logic anyway.

> > +if not cc.has_type('locale_t', prefix: '#include <locale.h>') and cc.has_type('locale_t', prefix: '#include <xlocale.h>')
>
> I wouldn't mind a line break after the 'and'.

Ah, right, I am still learning what is allowed in this syntax... will do.

> Other than these comments, the patch looks fine to me.

Thanks. I will wait a bit to see if Peter has any other comments and
then push this. I haven't actually tested with Solution.pm due to
lack of CI for that, but fingers crossed, since the build systems will
now agree, reducing the screw-up surface.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2023-07-07 22:48:00 Re: MERGE ... RETURNING
Previous Message Andrey Chudnovsky 2023-07-07 21:16:05 Re: [PoC] Federated Authn/z with OAUTHBEARER