Re: Modular C library

[Alejandro Colomar]

Hi Damian,

On 12/29/22 14:03, Damian McGuckin wrote:
> Hi,
>
> On Thu, 29 Dec 2022, Alejandro Colomar wrote:
>
> > Every time I try to patch glibc, I come again to this idea: the standard C 
> > library is doomed to be a mess, because the standard mandates it. I'm 
> > considering writing a new C library that is designed as a hurd of 
> > microlibraries, which can be replaced independently.  One could mix'n'match 
> > each of those microlibraries, since they would only rely on the public 
> > interface of other functions, so implementation details would matter very 
> > little.  The headers would be organized and split, into (relatively-deep) 
> > directory trees.
> >
> > I'll write the functions with a c_ prefix, so that I'm able to reserve all c_* 
> > identifiers for use by this library, and all headers will start with <c/*>.
> >
> > With that, this library will be able to live side-by-side with any libc; and 
> > in fact will need it while it's incomplete and it's not the default system 
> > library.
> >
> > So far, I'll make my recent libstp be one of these micro libraries.
> >
> > If you're interested in it, I'll open a public git repo for it.
>
> Do not these exist?  One of them is called MUSL designed as a drop-in
> replacement for glibc.

musl has the same problem as any other libc that tries to follow the standard: 
headers

musl is implemented in a more modular way than glibc, but it still needs to 
provide the same public interface: gigantic headers that define exactly what the 
standard says; not more, not less.

musl is not allowed to change the header structure that ISO C mandates.  I'd 
like to provide just one or a few related functions per header file, and the 
header directory tree would give important hints about the relationship between 
functions.

Also, I'd like a library where each module is replaceable (e.g., you may like 
most of the library, but not the string functions because I made them 
inefficient for your use case); you may write your own "libc-string" module, and 
replace it in the system, and as long as it provides the same functionality, 
other modules that depend on it should continue working fine, and hopefully 
faster for your use case.  So you don't need to fork an entire libc just to 
replace a single function.

Also, since I don't care about backwards compatibility, I'll start off with some 
recent standard --C89 is dead in my book--, which allows me to do important 
improvements: I'll define most functions C99 inline, so that the compiler can 
see do the best job when compiling.  The compiler wouldn't need an entire 
library of inline functions to be able to optimize the mess in libc; and it 
would be even better: GCC can't transform code to use GNU functions from 
standard functions, because it doesn't know if they are available; having them 
inline tells the compiler the maximum information possible.

I don't expect that (ab)using inline would be a big problem to compilation 
times, since the compiler already does the equivalent job with its huge list of 
inline functions to supplant libc.  This would remove responsibility from the 
compiler and pass it to libc.  Long term, this would allow significantly 
reducing the compiler.

> Or have I mis-understood - Damian

Cheers,

Alex

--
<http://www.alejandro-colomar.es/>

OpenPGP_signature
Description: OpenPGP digital signature