From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 18:38:16 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91CF11065675 for ; Mon, 27 Apr 2009 18:38:16 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 505A78FC08 for ; Mon, 27 Apr 2009 18:38:16 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n3RIcb1V010844; Mon, 27 Apr 2009 14:38:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n3RIcan7010843; Mon, 27 Apr 2009 14:38:36 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 27 Apr 2009 14:38:36 -0400 From: David Schultz To: =?iso-8859-1?Q?G=E1bor_K=F6vesd=E1n?= Message-ID: <20090427183836.GA10793@zim.MIT.EDU> Mail-Followup-To: =?iso-8859-1?Q?G=E1bor_K=F6vesd=E1n?= , hackers@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: hackers@FreeBSD.ORG Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:38:17 -0000 On Thu, Apr 23, 2009, Gábor Kövesdán wrote: > Hello all, > > my name is Gábor Kövesdán. I'm a Hungarian student and I'll be working on > a BSD-licensed libiconv implementation for FreeBSD during this year's > Summer of Code program. It'll be based on NetBSD's Citrus iconv but there > is a lot to do besides porting. My mentor is Xin Li. Nice. I'm sure many people will thank you for this. One complaint I've heard about both our wide character implementation and Citrus iconv is that the internal (wchar_t) encoding depends on the current locale. (Basically it uses a packed binary version of whatever the external representation is.) The relevant standards allow this, but it can be a pain for application and library writers. One thing to think about is whether it would make more sense to standardize on something like UCS-4 for the internal representation.