Message-ID: <6956823dd669abc64183fc91e64dc2e56e31f3ea.camel@j-davis.com>
Subject: Re: Remaining dependency on setlocale()
From: Jeff Davis <pgsql@j-davis.com>
To: Peter Eisentraut <peter@eisentraut.org>, Thomas Munro
	 <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: Mon, 07 Jul 2025 17:56:03 -0700
In-Reply-To: <a8666c391dfcabe79868d95f7160eac533ace718.camel@j-davis.com>
References: <4c5da86af36a0d5e430eee3f60ce5e06f1b5cd34.camel@j-davis.com>
	 <1841102.1722982989@sss.pgh.pa.us>
	 <CA+hUKGK7qKDHgoh1HuvMhtcpAwwVBA5BDt33vCzYYqCLfQTtzw@mail.gmail.com>
	 <CA+hUKGLLTy155HTQ6HfHu5-XPNfoFgDsRVUWevj+O6p3UmvPkg@mail.gmail.com>
	 <a70d3db4b8291b61c6937c0c003aa70e2d2c3a9a.camel@j-davis.com>
	 <CA+hUKGL82jG2PdgfQtwWG+_51TQ--6M9XNa3rtt7ub+S3Pmfsw@mail.gmail.com>
	 <b19ea499a6d78c101dc55b61bfb42069b427445c.camel@j-davis.com>
	 <fa04b56430fa4b5da7311c2faa113f406c6d192a.camel@j-davis.com>
	 <CA+hUKGKcS-Zhi8Ud+tv2TanzXBQjH+WsLyPY9DUDXob5VoYAtg@mail.gmail.com>
	 <cd3517c7-ddb8-454e-9dd5-70e3d84ff6a2@eisentraut.org>
	 <d2e7d63c0cc98f425652527cf260a3e6da17d2b0.camel@j-davis.com>
	 <a1396f17f462ee6561820f755caaf2d12eb9fd15.camel@j-davis.com>
	 <9875f7f9-50f1-4b5d-86fc-ee8b03e8c162@eisentraut.org>
	 <a8666c391dfcabe79868d95f7160eac533ace718.camel@j-davis.com>
Content-Type: multipart/mixed; boundary="=-DpMW8zU8xd0rsNr9YhLc"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/6956823dd669abc64183fc91e64dc2e56e31f3ea.camel%40j-davis.com>
Precedence: bulk

--=-DpMW8zU8xd0rsNr9YhLc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2025-06-11 at 12:15 -0700, Jeff Davis wrote:
> > v1-0008-Set-process-LC_COLLATE-C-and-LC_CTYPE-C.patch
> >=20
> > As I mentioned earlier in the thread, I don't think we can do this
> > for=20
> > LC_CTYPE, because otherwise system error messages would not come
> > out
> > in=20
> > the right encoding.
>=20
> Changed it so that it only sets LC_COLLATE to C, and leaves LC_CTYPE
> set to datctype.
>=20
> Unfortunately, as long as LC_CTYPE is set to a real locale, there's a
> danger of accidentally depending on that setting. Can the encoding be
> controlled with LC_MESSAGES instead of LC_CTYPE?
>=20
> Do you have an example of how things can go wrong?

I looked into this a bit, and if I understand correctly, the only
problem is with strerror() and strerror_r(), which depend on
LC_MESSAGES for the language but LC_CTYPE to find the right encoding.

I attached some example C code to illustrate how strerror() is affected
by both LC_MESSAGES and LC_CTYPE. For example:

   $ ./strerror de_DE.UTF-8 de_DE.UTF-8
   LC_CTYPE set to: de_DE.UTF-8
   LC_MESSAGES set to: de_DE.UTF-8
   Error message (from strerror(EILSEQ)): Ung=C3=BCltiges oder
unvollst=C3=A4ndiges Multi-Byte- oder Wide-Zeichen
   $ ./strerror C de_DE.UTF-8
   LC_CTYPE set to: C
   LC_MESSAGES set to: de_DE.UTF-8
   Error message (from strerror(EILSEQ)): Ung?ltiges oder
unvollst?ndiges Multi-Byte- oder Wide-Zeichen

On unix-based systems, we can use newlocale() to initialize a global
variable with both LC_CTYPE and LC_MESSAGES set. The LC_MESSAGES
portion would need to be updated every time the GUC changes, which is
not great.

Windows would be a different story, though: strerror() doesn't seem to
have a variant that accepts a _locale_t object, and even if it did, I
don't see a way to create a _locale_t object with LC_MESSAGES and
LC_CTYPE set to different values. One idea is to use
_configthreadlocale(_ENABLE_PER_THREAD_LOCALE), and then use
setlocale(), which could enable us to use setlocale() similar to how we
use uselocale() on other systems. That would be awkward, though.

Thoughts? That seems like a lot of work just for the case of
strerror()/strerror_r().

Regards,
	Jeff Davis

[1]
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/configthr=
eadlocale?view=3Dmsvc-170

--=-DpMW8zU8xd0rsNr9YhLc
Content-Disposition: attachment; filename="strerror.c"
Content-Type: text/x-csrc; name="strerror.c"; charset="UTF-8"
Content-Transfer-Encoding: base64

I2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxsb2NhbGUuaD4KI2luY2x1ZGUgPHN0ZGlvLmg+
CiNpbmNsdWRlIDxzdHJpbmcuaD4KCmludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikgewog
IGNoYXIgKmN0eXBlID0gYXJndlsxXTsKICBjaGFyICptZXNzYWdlcyA9IGFyZ3ZbMl07CiAgc2V0
bG9jYWxlKExDX0NUWVBFLCBjdHlwZSk7CiAgc2V0bG9jYWxlKExDX01FU1NBR0VTLCBtZXNzYWdl
cyk7CgogIHByaW50ZigiTENfQ1RZUEUgc2V0IHRvOiAlc1xuIiwgc2V0bG9jYWxlKExDX0NUWVBF
LCBOVUxMKSk7CiAgcHJpbnRmKCJMQ19NRVNTQUdFUyBzZXQgdG86ICVzXG4iLCBzZXRsb2NhbGUo
TENfTUVTU0FHRVMsIE5VTEwpKTsKCiAgLyogRUlMU0VROiBpbGxlZ2FsIGJ5dGUgc2VxdWVuY2Ug
Ki8KICBwcmludGYoIkVycm9yIG1lc3NhZ2UgKGZyb20gc3RyZXJyb3IoRUlMU0VRKSk6ICVzXG4i
LCBzdHJlcnJvcihFSUxTRVEpKTsKICByZXR1cm4gMDsKfQo=


--=-DpMW8zU8xd0rsNr9YhLc--