From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3191 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: High-priority library replacements? Date: Thu, 25 Apr 2013 00:15:53 -0400 Message-ID: <20130425041553.GA13951@brightrain.aerifal.cx> 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 1366863364 21797 80.91.229.3 (25 Apr 2013 04:16:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Apr 2013 04:16:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3195-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 25 06:16:09 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 1UVDbL-0000Xj-Iz for gllmg-musl@plane.gmane.org; Thu, 25 Apr 2013 06:16:07 +0200 Original-Received: (qmail 13521 invoked by uid 550); 25 Apr 2013 04:16:06 -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 13513 invoked from network); 25 Apr 2013 04:16:05 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3191 Archived-At: Hi all, The recent thread "Best place to discuss other lightweight libraries" had me thinking we should really put together a list of high-priority library replacements that need to be done. I don't think I'll be the one to do them, but I wouldn't mind overseeing/mentoring someone working on them, or just getting somebody else interested in these projects. A few initial ideas: 1. A light, C, UTF-8-only Unicode library. The most important things it should implement are things needed by any application that presents text to the user, specifically line-breaking (UAX#14), bidi (UAX#9), identifying grapheme clusters, etc. Things like case- and normalization-insensitive comparison, application of Unicode-format collation rules, etc. would also possibly be useful. 2. SSL. The modern internet basically requires using SSL everywhere. We should be aiming/expecting to transition to a world where even non-login-based sites are 100% https; the threats of malicious http injection attacks from rogue or advertising-based access points has gotten too great. Unfortunately, all of the existing SSL implementations are bloated, buggy, and fail even the most basic robustness requirements. A good solution would be based on tomcrypt and would expose a minimal, simple API suited for event-loop-based or threaded use. It may also be useful to have an optional wrapper layer to expose an API that mimics openssl or gnutls. It should also be able to keep up with the changing demands of how to determine which certificate authorities are to be trusted. 3. Image format and compression (libpng, zlib, etc.). The existing libraries are full of atrociously bad error-handling practices, and quite bloated. These libraries should be well-factored so that programs that just want to read (the majority of use cases) don't have to pull in code for writing. Unfortunately the interfaces might not be so simple, since an important usage case is progressive rendering of partially-loaded images, both for the purpose of loading over slow network connections and for rendering thumbnails quickly. All of these libraries should: - Avoid namespace pollution. Only external symbols should be the public API and internal-use stuff prefixed with an ugly prefix that's extremely unlikely to clash with anything. - Avoid unnecessary allocation. Use caller-provided objects where possible or provide both options. - Have absolutely zero global state. That's all I can think of at the moment but I'm sure there are other needs I've come across and forgotten. Please feel free to supplement this list. Rich