From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7904 Path: news.gmane.org!not-for-mail From: Harald Becker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Build option to disable locale [was: Byte-based C locale, draft 1] Date: Mon, 08 Jun 2015 03:57:01 +0200 Message-ID: <5574F66D.2070803@gmx.de> References: <20150606214007.GA17398@brightrain.aerifal.cx> <55737684.7020803@gmx.de> <20150606231057.GZ17573@brightrain.aerifal.cx> <55738979.4030809@gmx.de> <20150607002459.GA17573@brightrain.aerifal.cx> <5574DAE7.8040101@gmx.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1433728640 20530 80.91.229.3 (8 Jun 2015 01:57:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Jun 2015 01:57:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7917-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 08 03:57:19 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Z1mJR-00013u-35 for gllmg-musl@m.gmane.org; Mon, 08 Jun 2015 03:57:17 +0200 Original-Received: (qmail 11488 invoked by uid 550); 8 Jun 2015 01:57:15 -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 11464 invoked from network); 8 Jun 2015 01:57:14 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: X-Provags-ID: V03:K0:hhq3TD0RBh1NIXgiaCjYIL9Tt1KXHugv57dMYa4E6Gv3ZWdI35A QFS9yjcWLys9bRKNSwG3DE0IwlRhWR6ksE4ZRrz4xBSE+Hfs3quyXix5Lozx/qe2J+JVY0C 17Fm6RZ3cY8F+1OjpNnbfGqE4Ef/xDsXu53BiUCIqreS8xPsXqXZKrycUGicUddRm0LqjSF K5IPb5C3mZmpSB/N/ygkg== X-UI-Out-Filterresults: notjunk:1;V01:K0:IXrfmJB7hnU=:I607vY4QYNACmxKieaJruY lQYJz41qmsvF1sLHZceq5euOHw7b+v9nqSMB9KunevbyvT98WDAAIAvWCyg/ITPHeXNmOnOqt BaHddHcEpbMtxwFAX0XQHrPnRLZCNLGyEF+WAsEJLxI286I71oQKa1qK8g8DBSpFN4tWJ6cEN gwWNQpy8Gh4xGL9f5hWsxH6bFjh5Mhb3+GBr1phvIZbVBm60AS4sKRblXZRx+80Bze89gF73w S4LSvjDZcDPW4jkhuDbhNcRg0XXrTwB7ARtWyh/SMrNpOiTUxWif1jRzRcpMJLFs8VgAl2UYk 3AEBQEakzKXLowaZ84rwLKkV33yX02wJ4uDScW2g2ux35kKUm8fZNp0/wgEpjbOxiNlx4ysjU duuK4ikgEyov0iOZkLzfOoaWcjf8T24NoVSr4j7Hb4ZDvVtvxK9JV/fhA8cGcz7KhDYYuUXbn F6QLLWVbV9xiyJwcGspHrj/PBU2orxwt/RKnh382Bzy4vEyvfJxU2AsAllHeggpSyswbit8Gx mpFEBoV4SbXNAbDpmNtTr8ulx7astVP3zGZ1lVdSCT1CjOrqpx0OUczyj0GYouAgsI6JA2OxP nZCGNYhSghJxnnyKQrGS65y+KyoAeVZhUBIovzuUnPs/X3crD+z7mip3nO+n5xRHge0RhcxFp zymwfKK4o28ySiQlTmupfUbmJ2eTEr3hoZOgNVWG2P19n21c3Grigf5TKEhp8TU/7RCA= Xref: news.gmane.org gmane.linux.lib.musl.general:7904 Archived-At: Hi Josiah ! On 08.06.2015 02:28, Josiah Worcester wrote: > To start with: keep in mind that in the case of static linking most of > this is not at all pulled in except when strictly necessary. Static > linking might be more relevant to your needs. You missed my lead in message: I don't talk about static linking (which is what I currently do, replacing other stuff). I'm looking for a really small shared C library. As I think, the time for many different char sets is gone, we should step toward a small lib which fits better for two purposes: 1) really small systems with a minimal set of operation (usually those systems work with ASCII only, pure C locale). 2) Systems which use ASCII for it's majority, and use only a base set of UTF-8 operation. This should be compatible for all systems using C locale, but does not fit full desktop system setups. The problem is: Stripping all the functions on every new release is too much work, so it needs some minimal support in the library build process. Which should be pure optional, enabling the full version as default. >>> - UTF-8 encoding and decoding >> May be of use to keep, if on bare minimum. > > Seeing as the UTF-8 decoder is very small already, I'd be shocked if > you could make an argument for removing that. That's why I told "keep". I know it to be small, so keep it small and fast, and UTF-8 only (not supporting other multi byte char sets). > >>> - Character properties >> >>> - Case mappings >> >> Keep ASCII, map all none ASCII to a single value. > > This would be not-quite-right. Also, the case mapping tables are quite > small. towctrans.lo which contains the case mappings is 1106 bytes. Sorry for my poor English. I mean, let all functions behave as for locale "C" (ASCII), but don't fail / break when there is an embedded UTF-8 sequence. Just say "this is not ASCII" or may be: "this is UTF-8". >>> - Internal message translation (nl_langinfo strings, errors, etc.) >> >>> - Message translation API (gettext) >> >> No translation at all, keep the English messages (as short as possible). > > musl does not have any translations in it at all. It only has a small > portion of logic able to load external translations. locale_map.lo and > __mo_lookup.lo which are together responsible for this, are a total of > 1471 bytes. I mean drop the portion to load external translations. >>> - Charset conversion (iconv) >> >> >> Copy ASCII / UTF-8, but fail for all other. > > Though quite possible, it's worth noting that musl iconv is not very > large. iconv.lo is 128408 bytes, or 125k. A big hunk to kick off. Just keep a stub that allows for ASCII and UTF-8 and 1:1 copy operation. Should be possible to draw that down to not more than 1k. > The regex equivalence classes are handled via the isw* functions which > (as mentioned above) are quite small. So handle them as for the "C" locale, but don't fail/break when someone enters an UTF-8 sequence. > In short, it seems like if we made these changes we'd maybe be able to > trim out 135k and almost all of that would be in iconv. Though I > appreciate the desire for smaller code, this doesn't quite seem like > the place to go looking. My request is, to get a shared lib which does not need to include all that other char set and locale code. An optional build option, but with the need of some minimal support, so it can persist for future releases. I dislike doing all the strip down work over and over again for any new release. The resulting library shall be standards conform and fully operational, as long as the applications only use the bare C locale, but should allow to pass through embedded UTF-8 sequences. -- Harald