Date: Sun, 28 Jan 2024 19:08:49 +0100
On Sun, Jan 28, 2024 at 6:43 PM Tom Honermann <tom_at_[hidden]> wrote:
> 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?
>
Well, C does not have locale objects (and at this point I hope they don't
make the same mistakes c++ did so it's for the best) so they would have to
do something like iconv (ie string or id based) if they wanted to generalize
> 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
>>
>
>
> 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?
>
Well, C does not have locale objects (and at this point I hope they don't
make the same mistakes c++ did so it's for the best) so they would have to
do something like iconv (ie string or id based) if they wanted to generalize
> 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
>>
>
>
Received on 2024-01-28 18:09:09