Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120713191609.GC14463@port70.net>
Date: Fri, 13 Jul 2012 21:16:09 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Draft: musl promo materials

* Rich Felker <dalias@...ifal.cx> [2012-07-13 14:12:54 -0400]:
> Consistent quality and implementation behavior from tiny embedded
> systems to full servers.
> 
> Minimal machine-specific code, meaning less chance of breakage on
> minority architectures and better success with "write once run
> everywhere" development.
> 
> Realtime-quality robustness. No unnecessary dynamic allocation. No
> unrecoverable late failures. No lazy binding or lazy allocation.
> 
> MIT license.
> 
> Full math library with a focus on correctness. Exact and
> correctly-rounded conversion between binary floating point and decimal
> strings.
> 
> Reentrancy, thread-safety, and async-signal safety well beyond the
> requirements of POSIX. Even snprintf and dprintf are fully reentrant
> and async-signal-safe.
> 
> Highly resource-efficient POSIX threads implementation, making
> multi-threaded application design viable even for memory-constrained
> systems.

i'd somehow add that both static and dynamic linking is supported
properly and without bloat as musl is better at it than glibc

i like musl's clean code, clean header files (no gcc specific mess)
and simple build system (even for cross compilation)
again something that glibc is lacking

and there could be a hint that things like security, worst cases
(stack usage, algorithm complexity) and conformance are taken seriously

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.