Re: Make uselocale protection more consistent

On Mon Jul 3, 2023 at 1:24 AM CDT, Thomas Munro wrote:
> On Mon, Jul 3, 2023 at 6:13 PM Peter Eisentraut  wrote:
> > On 27.06.23 17:02, Tristan Partin wrote:
> > > This is a patch which implements an issue discussed in bug #17946[0]. It
> > > doesn't fix the overarching issue of the bug, but merely a consistency
> > > issue which was found while analyzing code by Heikki. I had originally
> > > submitted the patch within that thread, but for visibility and the
> > > purposes of the commitfest, I have re-sent it in its own thread.
> > >
> > > [0]: https://www.postgresql.org/message-id/49dfcad8-90fa-8577-008f-d142e61af46b@iki.fi
> >
> > I notice that HAVE_USELOCALE was introduced much later than
> > HAVE_LOCALE_T, and at the time the code was already using uselocale(),
> > so perhaps the introduction of HAVE_USELOCALE was unnecessary and should
> > be reverted.
> >
> > 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.

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