Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Feb 2015 14:59:36 +0530
From: Raphael Cohn <>
Subject: Re: What would make musl 1.2?

Is there any possibility of adding in the ucontext.h functions? I know
they're deprecated, but they're still widely used - particularly by go for
goroutines, IIRC. I realise there are problems correctly implementing the
*_r variants, but a well-written, modern and efficient implementation would
be a big win.

On 13 February 2015 at 13:16, Rich Felker <> wrote:

> We're far enough along in the 1.1.x series now that I'd like to start
> thinking about what milestones might justify calling a release 1.2.0.
> Looking at the Open Issues and Roadmap on the wiki, the big things
> musl could gain in the near future look to be:
> - Finishing up all the loose ends on locale and multilingual support:
>   IDN, message translations, iconv improvements, collation, and
>   possibly the byte-based C locale.
> - Hardening/security features.
> - C++11 non-POD TLS.
> - Alternate user/group db backends (hopefully in upcoming 1.1.7).
> Any or all of these could become part of the wishlist for 1.2.
> Aside from those big functionality areas though, I think archs/porting
> might be one of the most important things to think about. Supporting
> aarch64 is definitely important in the near future, and it could be a
> big publicity boost. So could getting coverage for the remaining archs
> uClibc has that musl doesn't, or at least the ones of modern interest.
> Other ideas?
> Rich

Content of type "text/html" skipped

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.