From owner-svn-src-head@FreeBSD.ORG Sat May 25 19:57:11 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D8D77588; Sat, 25 May 2013 19:57:11 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 9E32B284; Sat, 25 May 2013 19:57:11 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 8347812013A; Sat, 25 May 2013 21:56:59 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 5B7F728493; Sat, 25 May 2013 21:56:59 +0200 (CEST) Date: Sat, 25 May 2013 21:56:59 +0200 From: Jilles Tjoelker To: Ed Schouten Subject: Re: svn commit: r250883 - in head: include include/xlocale lib/libc/locale sys/sys tools/regression/lib/libc/locale Message-ID: <20130525195659.GB26980@stack.nl> References: <201305211959.r4LJxbLx034714@svn.freebsd.org> <20130521220003.GB58299@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, gabor@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 19:57:11 -0000 On Sat, May 25, 2013 at 04:00:44PM +0200, Ed Schouten wrote: > [ +gabor ] > 2013/5/22 Ed Schouten : > > 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. > So I think the solution to this problem is twofold. First, let's look > at the case where people have built world with WITH_ICONV=. Instead of > implementing the *c32* functions on top of the *wc* variants, we can > simply use libiconv. The following patch adds two new variants of the > *c32* functions, implemented on top of libiconv. > At first I tried implementing these functions on top of > iconv_open_into(), but unfortunately it seems to be the case that the > iconv_allocation_t is larger than the mbstate_t, meaning we cannot > safely embed one into the other. To work around this, I'm using the > internal _citrus_* API. > http://80386.nl/pub/uchar-iconv.txt > Jilles, Gabor, could you please take a look at the patch, whether it's > any good? The idea seems good. I have not tested it, though. It seems better to implement c16rtomb_l() and mbrtoc16_l() in the same way, rather than duplicating the UTF-16 coding and passing a pointer to a mbstate_t which actually has only 120 bytes of storage rather than the required 128 bytes. > Now we still have the case where the system is built WITHOUT_ICONV=. I > think it really depends on the future of iconv in base how complete we > should attempt to make it. Gabor, is there a chance WITH_ICONV= will > become the default in FreeBSD 10? If ache@ is right about configure scripts, it is an option to expose the new functions only for WITH_ICONV=. -- Jilles Tjoelker