Date: Sat, 14 Jul 2012 14:40:05 +0800 From: orc <orc@...server.ru> To: musl@...ts.openwall.com Subject: Re: Draft: musl promo materials On Fri, 13 Jul 2012 21:16:09 +0200 Szabolcs Nagy <nsz@...t70.net> wrote: > * 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 Agree with that. musl allowed me implement a variant of skein crypt() for example, and much more things than mess called glibc. It's source code is easy to understand and good start point to learn how libc works. > > 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.