From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3831 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: iconv Korean and Traditional Chinese research so far Date: Mon, 5 Aug 2013 08:54:57 -0400 Message-ID: <20130805125456.GG221@brightrain.aerifal.cx> References: <20130804165152.GA32076@brightrain.aerifal.cx> <20130805003943.050fc58e@ralda.gmx.de> <20130805004420.GL25714@port70.net> <20130805032452.280127fd@ralda.gmx.de> <20130805031322.GM25714@port70.net> <20130805090343.6d2f9f00@ralda.gmx.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1375707310 15963 80.91.229.3 (5 Aug 2013 12:55:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Aug 2013 12:55:10 +0000 (UTC) Cc: nsz@port70.net To: musl@lists.openwall.com Original-X-From: musl-return-3835-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 05 14:55:13 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V6KJa-0008Kl-Uk for gllmg-musl@plane.gmane.org; Mon, 05 Aug 2013 14:55:11 +0200 Original-Received: (qmail 26597 invoked by uid 550); 5 Aug 2013 12:55:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26587 invoked from network); 5 Aug 2013 12:55:10 -0000 Content-Disposition: inline In-Reply-To: <20130805090343.6d2f9f00@ralda.gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3831 Archived-At: On Mon, Aug 05, 2013 at 09:03:43AM +0200, Harald Becker wrote: > The only code that get a bit more, is the file system search. > This depends if we only try single location or walk through a > search path list. But this is the cost of flexibility to > dynamically load character set conversions (which I would really > prefer for seldom used char sets). The only "seldom used char sets" are either extremely small (8bit codepages) or simply encoding variants of an existing CJK DBCS (in which case it's just a matter of code, not large data tables, to support them). > .... and for application writer it is only more, if he likes to > add some charset tables into his program, which are not in > statical libc. This is only helpful if the application writer is designing around musl. This is a practice we explicitly discourage. > The problem is, all tables in libc need to be linked to your > program, if you include iconv. So each added charset conversion > increases size of your program ... and I definitly won't include > Japanese, Chinese or Korean charsets in my program. No that I > ignore those peoples need, I just wont need it, so I don't like > to add those conversions to programs sitting on my disk. How many programs do you intend to use iconv in that _don't_ need to support arbitrary encodings including ones you might not be using yourself? Even if you don't read Korean, if a Korean user sends you an email containing non-ASCII punctuation, Greek letters like epsilon, etc. there's a fair chance their MUA will choose to encode with a legacy Korean encoding rather than UTF-8, and then you need the conversion. It would be nice if everybody encoded everything in UTF-8 so the recipient was not responsible for supporting a wide range of legacy encodings, but that's not the reality today. > If the definition of the iconv virtual state machine is modified, > you need to do extra care on update (delete old charset files, > install new lib, install new charset files, restart system) ... > but this is only required on a major update. As soon as the Even if there were really good reasons for the design you're proposing, such a violation of the stability and atomic upgrade policy would require a strong overriding justification. We don't have that here. Rich