Re: Make uselocale protection more consistent

On Mon, Jul 3, 2023 at 6:13 PM Peter Eisentraut <peter(at)eisentraut(dot)org> 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