Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 7 Sep 2012 23:36:58 -0700
From: Isaac Dunham <>
Subject: Re: documenting musl

On Fri, 7 Sep 2012 22:40:06 -0400
Rich Felker <> wrote:

> Hi all,
> One item that's been on my todo list for a while, but didn't really
> make it into the last email, is creating some kind of documentation

> One document, which I would call simply the "manual", should cover
> everything you need to know if you're writing applications against
> musl or building existing applications against musl. It should contain
> introductory materials on the standards and extensions musl aims to
> support, feature test macros, etc. It should also document musl's
Just wrote up a preliminary draft for this part.
> locale behavior, quality of implementation guarantees, and anything

I'm not certain about these, myself.
> ISO C or POSIX requires an implementation to document (i.e.
> implementation-defined behavior). In some cases, the documentation may
> defer to that for the compiler being used. The manual should further
> document any additional behavior guarantees for functions beyond
> what's required in the standard, as well as behavior for all supported
> non-standard functions.
> A second possible document would be oriented towards people wanting to
> learn from the source, port musl to new platforms, add features or

start with the "Porting" docs?

> customize it for unusual usage cases, reuse parts of musl in other

I presume this includes (for example) builds without src/complex/ and
stripping it down for embedded use? I've been doing a few experiments
in that way.

> software, etc. This document would explain the source tree layout and
> build system, use of weak symbols and object file dependency graph
> issues, stdio and pthread internal interfaces including thread
> cancellation architecture, porting requirements, and so on.

> Ideas? Volunteers?

I can do some of this.
I'm thinking about turning some of these into man pages.
eg, musl-standards, musl-features, musl-porting, musl-implementation...
Also, manpages for functions not covered by linux-manpages-dev (fgetln,
strl*, ...) _might_ be in order.

View attachment "musl-man.txt" of type "text/plain" (2200 bytes)

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.