From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14103 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Funktion for converting strings from / to UTF-16 and UTF-32? Date: Mon, 29 Apr 2019 18:24:12 -0400 Message-ID: <20190429222412.GW23599@brightrain.aerifal.cx> References: <8959bfe3-14ac-1fa5-7423-d3e093d81e11@informatik.uni-freiburg.de> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="252131"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14119-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 30 00:24:29 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hLEhJ-0013Os-0j for gllmg-musl@m.gmane.org; Tue, 30 Apr 2019 00:24:29 +0200 Original-Received: (qmail 17731 invoked by uid 550); 29 Apr 2019 22:24:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17710 invoked from network); 29 Apr 2019 22:24:25 -0000 Content-Disposition: inline In-Reply-To: <8959bfe3-14ac-1fa5-7423-d3e093d81e11@informatik.uni-freiburg.de> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14103 Archived-At: 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