Date: Wed, 6 May 2009 18:22:47 +0200 From: Joerg Sonnenberger <joerg@britannica.bec.de> To: freebsd-hackers@freebsd.org Subject: Re: SoC 2009: BSD-licensed libiconv in base system Message-ID: <20090506162247.GA23015@britannica.bec.de> In-Reply-To: <3cb459ed0905060328n4ad05d98xb5ba0c2e01d356e2@mail.gmail.com> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> <20090428122225.GA2862@britannica.bec.de> <24e9a86bf5995ba551db8f27aa204191.squirrel@webmail.kovesdan.org> <20090428180624.GA2223@britannica.bec.de> <4A00B897.809@FreeBSD.org> <3cb459ed0905060328n4ad05d98xb5ba0c2e01d356e2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 06, 2009 at 02:28:51PM +0400, Alexander Churanov wrote: > 1) Why discuss UCS-4 at all? UTF-32 is alreay in place. SImple, > standardized, fixed-width and stateless. Which part of "combining characters" is stateless? Sure, you can ignore that in some/many applications, but it still exists. UCS-4 and UTF-32 are identical, so discussing one is enough. > 2) I'm against using wchar_t internally, because C language standard > does not require that a wchar_t variable can hold an UTF-32 code > point. See my original point of that locale independent wchar_t might be useful, but creates problems. If the OS supports full Unicode 3+ locales, it will have to be able to fit any UCS-4 code point into wchar_t. Joerg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090506162247.GA23015>