On 1/28/24 11:40 AM, Corentin Jabot via SG16 wrote:
>
>
> On Sun, Jan 28, 2024 at 5:26 PM Tom Honermann via SG16
> <sg16_at_[hidden]> wrote:
>
> On 1/26/24 10:00 AM, Tom Honermann via SG16 wrote:
>> On 1/26/24 9:46 AM, Corentin Jabot via SG16 wrote:
>>> Yes. they do complete the existing C11 set
>>> with mbrtoc[16|32]/c[16|32]rtomb (damn, these names)
>> Yup. That is exactly why they were added; despite the known
>> limitations of the existing functions.
>>> I agree with you that it's unfortunate that they do rely on a
>>> global state, but still useful when dealing with the execution
>>> encoding. maybe glibc can provide the same functions with an
>>> additional locale param,
>>> I'm sure that would be useful to c++ implementations.
>>
>> Or we just standardize a new and appropriate transcoding facility :)
>
> What I think I would like to see is:
>
> 1. A way to identify the encoding associated with an arbitrary
> locale.
>
> https://eel.is/c++draft/locale#lib:locale,encoding

Indeed, that should work for C++. I copied my last message from a thread
on the WG14 mailing list and, for C, we would need analogous
functionality to query the C notion of a locale. Unfortunately, an
encoding can be specified separately for each locale category, so it
isn't clear to me how that would work; perhaps just take the encoding
from LC_ALL or LC_CTYPE?

Tom.

> 1. A general transcoding facility that is implementable as a
> light wrapper over iconv(), MultiByteToWideChar() and
> WideCharToMultiByte(), or ICU's converters
> <https://unicode-org.github.io/icu/userguide/conversion/converters.html>.
>
> Tom.
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>