regexps.com
The Hackerlab C Library is a general purpose library for C programs running in Posix compatible environments.
Development of the library is ongoing.
                Paradise is exactly like where you are right now, 
                only much, 
                much,
                BETTER.
                        Laurie Anderson
The standard C library was never designed. It simply "happened", in several stages.
As nearly as I can tell, it started off as a collection of routines
needed to write the very first unix shell tools.  Some good coding
habits developed around this time (keeping interfaces simple, for
example).  There are little flashes of systematic design, but no
sign of a sustained effort to think through what should be in a 
clean and complete C library -- I guess they were too busy inventing
grep
 and such.
Then, as Unix spread, the C library grew. BSD hackers added a bunch of functions, for example. Still, nobody sat down to make it a nicely designed library.
Standards came along, and they (mostly) tried to codify the C library that already existed.
Nowadays, people take the C library for granted. That's a shame, because if you have a nicer library, the programs that use that library are likely to be simpler, more powerful, and more correct.
That's where libhackerlab
 comes in.  The goal is to completely
replace all of libc, except for very system dependent parts, such
as system call interfaces.  In replacing libc, we want to build 
something much, much, BETTER.  We want a more complete selection
of functions, with clearer names, and more consistent interfaces.
Whenever possible, we want greater generality.
Some parts of libhackerlab
 are reasonably complete, tested, and
stable.  Others are less so.  We've tried to make clear in this
manual which parts are which.
Write to hackerlab@regexps.com
 if you have something to contribute.
Here are some suggestions for what volunteers might do:
        Help With Porting
                Recently, we've only been testing the library
                on one BSD-based platform.  It should be easy
                to port to other varieties of unix.
        Work on test cases.
                We use lots and lots of unit tests
                for this code.  Some subsystems are 
                lacking unit tests.  That's very bad.
        Work on data sheets.
                We like to write a data sheet for every major
                subsystem of the library.  Data sheets should describe
                the subsystem: its recommended uses; situations in
                which not to use it; the size of the code; the
                performance of the code, etc.  You can see some
                example data sheets at the end of this manual.  More
                are needed.
                We also need some tools that will keep the data
                sheets up to date automatically -- currently
                they are maintained by hand (including cutting
                and pasting benchmark results, for example).
        Use it in your programs -- tell us what works and what 
        doesn't.
                We think the design so far is quite nice, and
                our experience using the library seems to 
                confirm this, but your milage may vary.
                Let us know.
        Contribute New Subsystems to the Library
                This is a tricky one.  In all probability,
                we won't like your design prejudices or 
                coding style.  But heck, give it a try.
        Work on floating point I/O
                We need fast and accurate functions for
                converting between floating point values
                and strings.  We need support for floating
                point in printfmt.
        Work on a scanf replacement.
                We have printfmt, which replaces printf,
                but we have no replacement yet for scanf.
        Give us money.
                Pay a download fee when you grab a copy of
                libhackerlab -- helps us pay for much needed
                electrons, rent, food, and other goodies.
                Generally speaking, getting paid is a precondition
                of doing more work on Hackerlab software at
                a reasonable pace.
                If you want to spend a whole bunch of 
                money, Talk To Us About Our Business Plan.
        Work for the Hackerlab
                If you are an excellent Hacker, and you
                like libhackerlab, and you want to help
                start a software R&D lab, and you feel
                like pursuing a long shot -- send us a
                resume or code samples or something.
                It helps if you live in the Bay Area
                of Northern California, USA.  (No, we have
                no paid positions to offer just yet.)
libhackerlab: The Hackerlab C Library
regexps.com