Date: Wed, 22 May 2013 07:43:35 +0400 From: Andrey Chernov <ache@freebsd.org> To: Ed Schouten <ed@80386.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: svn commit: r250883 - in head: include include/xlocale lib/libc/locale sys/sys tools/regression/lib/libc/locale Message-ID: <519C3EE7.1000800@freebsd.org> In-Reply-To: <CAJOYFBD6RKPaGRF7oD54rGcYcZBnL9ZfJSCfLvu21XMcyZ13_w@mail.gmail.com> References: <201305211959.r4LJxbLx034714@svn.freebsd.org> <20130521220003.GB58299@stack.nl> <CAJOYFBD6RKPaGRF7oD54rGcYcZBnL9ZfJSCfLvu21XMcyZ13_w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22.05.2013 2:20, Ed Schouten wrote: > 2013/5/22 Jilles Tjoelker <jilles@stack.nl>: >> Our wchar_t is only ISO 10646 for UTF-8 and possibly US-ASCII and >> ISO8859-1 (subset) locales. > > Oh, the horror! I thought on FreeBSD, we used the LC_CTYPE files to do > a mapping to ISO 10646. Unfortunately, it seems to be the case that > these files are only used to do mappings to > uppercase/lowercase/runetype. Bummer. > > I'll see what I can do to fix this. I'll likely implement something > like you suggested, that we return EILSEQ if the locale is not ASCII, > ISO8859-1 or UTF-8. Yes, non UTF-8 and its subsets locales are not encoded in ISO 10646 internally but have their own internal encoding. Returning EILSEQ will broke them all at once, so I see no point to add new functions such way, because GNU configure will sense them, and then they doesn't work. Proper way is ether to not add them or use lib/libc/iconv for them (adding a lot of missing locales into lib/libiconv_modules). -- http://ache.vniz.net/ bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?519C3EE7.1000800>