Minilib evolved out of some assembler experiments, where I saw how tiny executables can be, if not linked with glibc. With some more fiddling I got a C "Hello World!" binary with 151 bytes, compiled and linked with the standard gcc makechain. This is more than 3,000 times less than a hello world program linked statically with glibc, which shows up with 504kB on my system. (5.4kB linked dynamic)
(On OSX there are some limits, files with less than 4k aren’t executed, so that’s hello world’s size there..)
minilib saves a lot of startup overhead, no linker needed to bind the shared libraries, no lookup tables, less memory fraction; also (small) binaries might often fit into a single harddisk block; opposed to a binary and several shared libraries.
This gives a overall more responsive system.
Just for fun, but this minilib also beats klibc, dietlib and musl in the matter of hello world’s size..
(Linux 32bit:) musl: 7.6k dietlibc: 672 klibc: 367 minilib: 151
(On Linux 64bit I didn’t check the other libraries, but the bigger registers cost a few bytes: hello world counts here 185 Bytes.)
Being in syscalls, linker scripts and gcc optimization hell, I realized, that after I got over the fundamental problems adding more standard c routines would be cheap. So I started to port some more little c tools to minilib, adding more functionality to minilib as well.
Since I hate todays usual overhead in modern libraries, resulting in the unbelievable size of hundreds of Megabytes for simple applications as well as minutes for just starting them up, I also tried to optimize functions like printf where sensible.
The focus is on size, however. You are able to customize the compilation of the library and define just only the functions you need; if you are in need of, e.g., a more speed optimized strcmp, just don’t define the according switch and rule your own.
This whole project exaggerated out of fun.
But, when looking at it now, minilib got a quite comprehensive toolbox.
There’s some tidying to do, and the documentation is lacking.
However, since I’m using the library within several other tools, it get’s more and more stable.
Ansi C89 is done mostly, not counting floating math and localizations.
For both cases I’m going to incorporate external libraries; there’s the library openm, or openmath for floating point routines. And there might be something out there for localizations.
Especially floating point routines I believe are better given by another framework, which also suites the different architectures/cpu instruction sets.
Next step will be to bring in routines, deviating of the standards.
There are already several small helper functions and macros, e.g. ewrites() for writing a string constant to stderr.
They are documented as well, within the "reference". But, there’s obviously a better categorization of the documentation needed.
Now I’m going to bed. There’s one function left, "putenv". I somehow do not like the way, the function works. Useless copying of bytes from there to there. But, it is defined in C89; so,.
And malloc does need a more comprehensive implementation. For now, dynamic allocations (besides the static buf, which is used for malloc now can be done with malloc_brk.
Albite I’m still a bit struggling, somehow I do believe all overall, malloc is more a case for a user library than for a system library. It’s impossible to know the usecase in advance.
Since minilib is configured fine grained, it is possible to provide several implementations. The curent implementation is more than simplilistic, just a few lines, and e.g. sparse free’d areas aren’t reused.
Reusing free’d sparse memory areas is not that hard to implement. But it’s hard to find a good way between code size and speed optimization. Without knowing the use cases.
Anyways. Good night.