Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 12 Jul 2014 01:10:35 -0400
From: Rich Felker <>
Subject: Status towards next release (1.1.4)

I think we're pretty well on-schedule for the next release. Here's a
summary of progress so far:

- Private futex support, not committed. If we can demonstrate any
  performance benefit, it can be committed, but otherwise I'm inclined
  to throw it out. There's no point in adding complexity with no
  evidence of benefit.

- Locale framework. Right now this is mostly just a framework and does
  nothing useful.

- Byte-based C locale, not committed. As discussed previously, this is
  non-essential for conforming to current standards, so I'm inclined
  to omit it for now. But if there's demand for it we can consider
  adding it.

- Gettext/mo file lookup core. This is not integrated with libc yet,
  but tested and working.

- Openrisc (or1k) port. Stefan Kristiansson's work seems basically
  complete and is in the testing phase now. I'm hoping to merge it
  in the next few days.

There are several things we need to focus on now:

- The Big Bikeshed: where to find locale files? These will be somewhat
  musl-specific (to the extent that no other implementation uses the
  design I have in mind, though it would be easy for others to use
  it), so there's no existing practice to simply adopt. The files are
  not machine-specific (we'll support either endianness .mo file) so
  /usr/share (or other prefix variants) is the natural base location.

- Minor coding tasks for locale. Really, this is minor. The policy of
  where to find the files is a much bigger issue to work out.

- Adding non-stub public gettext API. I'd like this to happen along
  with the locale work since it uses the same core operation, but it
  may turn out that there are various bloated gettext features which
  applications use which we don't want in the core libc itself uses
  for locale, in which case we'd end up with two implementations.

- What to do with if_nameindex and getifaddrs? This issue has been
  deferred for a couple releases now so I really want to solve it this

The other items on the roadmap are all secondary and related to ports.
I'll be happy if we can just get or1k into this release, since it's a
nice way to draw some publicity for both projects (musl and openrisc).
But if there's time, I might do the bits refactoring (and other
port-related cleanup) in this release cycle once or1k is committed.


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.