Roman Shaposhnik's

Once upon a time there was a small project called GNU, and they wanted to build a system which wouldn't be UNIX but rather a free ad lib giving every human being a power to tinker with a capable computing environment. Their goal was a noble one and they started off with building one cornerstone tool for building everything else – the C environment. And thus Gcc and Glibc were created. Of course, because of the evil spell of a particular committee Glibc had to suffer a multiple personality disorder from the day it was born. Because you see, every libc has to serve two masters at the same time by being a pure language library (just like, say, C++ standard library) but also by being an interface to the underlying OS take care of the system calls. Of course, since the GNU project didn't really want to have a UNIX kernel at their core GNU libc had to work with HURD. And so it did. Faithfully. And it was a nice piece of software (that is to the extent anybody can call GNU coding style nice).

Then 1991 came a long and Linux was in, that is – shopping for a suitable C library to suit its kernel needs. GNU libc, of course, was an obvious choice not only because it was GNU software, but because it was paired up with gcc – a compiler of choice for early Linux developers. Of course, nobody wanted to deal with triple personality disorder (Glibc would have to support two kernels at the same time) so they forked. And both pieces of software remained to be pretty good. The only problem was – Linux kernel developers were not really interested in developing the language personality of libc: after all they “don't do userspace”. So it wasn't really a surprise when around 1997 they determined that it was easier to add support of Linux kernel into the vanilla GNU libc (and chage the version from 5.X to 2) than to add all those features of GNU libc back into their fork.

And thus a monster of complexity was born. Because by that time Glibc was really going out of its way to support everything and the kitchen sink. All of the UNIX standards fashionable at the time and on top of that a bunch of dubious extensions. The reasoning was simple: “because we can”.

At that time I still felt for GNU libc (even though personally I do believe in “small is beautiful”) at least they had their excuse for being as bloated and complicated (does declaring a function really need to require 32 lines of code and 4 different macros?) as they were. But it all came crumbling down when I read this post from a raving^H^H^H^H^Hoppinionated GNU libc project lead Dictatorship of the Minorities.

So, I figured, if GNU libc is now officially a Linux only project may be its time to clean it up or just throw it away and replace it with the proper C99 compliant libc which wouldn't be rated “M” for the purposes of reading the code ? Like a Solaris libc or a Plan9 libc or an Mplayer libc or a BSD libc – anything but the stuff that has incorrect C99 code in its headers.

I know Linus would agree. Any takers ?

P.S. In the ideal world, of course, libc would be also purged from a split personality disorder and made into two libraries – one for supporting system calls and system aspects of POSIX and the other one for supporting C language. The later will have to be shipped with a compiler and made as fast as possible using things like IR inlining. Oh well, a topic for a different post I suppose.