On Sun, Jan 28, 2024 at 5:26 PM Tom Honermann via SG16 <sg16@lists.isocpp.org> 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:
- A way to identify the encoding associated with an arbitrary locale.
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.
--
- A general transcoding facility that is implementable as a light wrapper over iconv(), MultiByteToWideChar() and WideCharToMultiByte(), or ICU's converters.
Tom.
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16