[<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.
