[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130425041553.GA13951@brightrain.aerifal.cx>
Date: Thu, 25 Apr 2013 00:15:53 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: High-priority library replacements?
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
