Funktion for converting strings from / to UTF-16 and UTF-32?

Funktion for converting strings from / to UTF-16 and UTF-32?

[Philipp Klaus Krause]

[-- Attachment #1.1: Type: text/plain, Size: 412 bytes --]

Would musl be interested in adding support for functions that convert
from / to UTF-16 and UTF-32 (assuming that char16_t is UTF-16 and
char32_t is UTF-32)?

There is the proposal N 2282, which was discussed half a year ago at the
Pittsburg meeting of WG 14; back then the comitee wanted to see a second
implementation fo these functions (the library that comes with SDCC
already has them).

Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Funktion for converting strings from / to UTF-16 and UTF-32?

[Rich Felker]

On Mon, Apr 29, 2019 at 08:27:35PM +0200, Philipp Klaus Krause wrote:
> Would musl be interested in adding support for functions that convert
> from / to UTF-16 and UTF-32 (assuming that char16_t is UTF-16 and
> char32_t is UTF-32)?
> 
> There is the proposal N 2282, which was discussed half a year ago at the
> Pittsburg meeting of WG 14; back then the comitee wanted to see a second
> implementation fo these functions (the library that comes with SDCC
> already has them).

I'm not sure. They seem to be of limited usefulness - UTF-16 is
legacy, and UTF-32 is the same as wchar_t on any implementation that
actually supports UTF-32 (at least wchar_t has to cover the whole
Unicode codepoint space, so 16-bit is out and the only reason it could
be anything other than UTF-32 is gratuitous incompatibility).

Of course we'll support this if it's standardized as a required
interface for future C versions, but I'm not sure it's in line with
musl's philosophy or criteria for inclusion to be trying to advance
these interfaces into a standard without a good argument that they're
important to have (if you believe they are, I'm open to hearing that
and seeing what others think).

Rich

Re: Funktion for converting strings from / to UTF-16 and UTF-32?

[Philipp Klaus Krause]

I mostly agree with your opinion on the UTF-32 functions. They had been
added to the proposal in response to comments on earlier drafts. AFAIK
the addition of char32_t probably was in part a response to platforms
that do not use a UTF-32 wchar_t.
If the proposal is put up for straw poll at WG14 again, I'd suggest
separate polls for the UTF-16 vs UTF-32 functions.

For implementation experience, the UTF-16 functions is what matters.

I do consider the UTF-16 / char16_t functions to be quite useful.
UTF-16 is still quite relevant today. The format has found its way into
many specifications, such as USB and file systems so there are important
use case in converting from / to UTF-16.

Philipp