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.
 2. 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.