Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 May 2013 21:56:59 +0200
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Ed Schouten <ed@80386.nl>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, gabor@freebsd.org
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>
In-Reply-To: <CAJOYFBBwpO8sCh-78G7wndbqK3vj4OB-x-h-=Hk_s7FTvAgNZQ@mail.gmail.com>
References:  <201305211959.r4LJxbLx034714@svn.freebsd.org> <20130521220003.GB58299@stack.nl> <CAJOYFBD6RKPaGRF7oD54rGcYcZBnL9ZfJSCfLvu21XMcyZ13_w@mail.gmail.com> <CAJOYFBBwpO8sCh-78G7wndbqK3vj4OB-x-h-=Hk_s7FTvAgNZQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 25, 2013 at 04:00:44PM +0200, Ed Schouten wrote:
> [ +gabor ]

> 2013/5/22 Ed Schouten <ed@80386.nl>:
> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130525195659.GB26980>