Subject: Re: Make uselocale protection more consistent

From: Peter Eisentraut <[email-masked]>
Date: Mon, 3 Jul 2023 16:21:04 +0200

On 03.07.23 15:21, Tristan Partin wrote:
>>> I think it would be better to keep HAVE_LOCALE_T as encompassing any of
>>> the various locale_t-using functions, rather than using HAVE_USELOCALE
>>> as a proxy for them.  Otherwise you create weird situations like having
>>> #ifdef HAVE_WCSTOMBS_L inside #ifdef HAVE_USELOCALE, which doesn't make
>>> sense, I think.
>> I propose[1] that we get rid of HAVE_LOCALE_T completely and make
>> "libc" provider support unconditional.  It's standardised, and every
>> target system has it, even Windows.  But Windows doesn't have
>> uselocale().
>>
>> [1]https://www.postgresql.org/message-id/flat/CA%2BhUKGL7CmmzeRhoirzjECmOdABVFTn8fo6gEOaFRF1Oxey6Hw%40mail.gmail.com#aef2f2274b28ff8a36f9b8a598e3cec0
> I think keeping HAVE_USELOCALE is important for the Windows case as
> mentioned. I need it for my localization work where I am ripping out
> setlocale() on non-Windows.

The current code is structured

#ifdef HAVE_LOCALE_T
#ifdef HAVE_WCSTOMBS_L
     wcstombs_l(...);
#else
     uselocale(...);
#endif
#else
     elog(ERROR);
#endif

If you just replace HAVE_LOCALE_T with HAVE_USELOCALE, then this would 
penalize a platform that has wcstombs_l(), but not uselocale().  I think 
the correct structure would be

#if defined(HAVE_WCSTOMBS_L)
     wcstombs_l(...);
#elif defined(HAVE_USELOCALE)
     uselocale(...);
#else
     elog(ERROR);
#endif

---

From: "Tristan Partin" <[email-masked]>
Date: Mon, 03 Jul 2023 09:49:21 -0500

> #elif defined(HAVE_USELOCALE)

That makes sense to me. I gave it some more thought. Maybe it makes more
sense to just completely drop HAVE_USELOCALE as mentioned, and protect
calls to it with #ifdef WIN32 or whatever the macro is. HAVE_USELOCALE
might be more descriptive, but I don't really care that much either way.

-- 
Tristan Partin
Neon (https://neon.tech)