dietlibc VS glibc

- Dietlibc: https://www.fefe.de/dietlibc/

The commercial success of a product totally depends on the business model you come up with, whatever be its opensource (or not) license.

Corporates have a vested interest in promoting the propaganda that only a non-xGPL opensource license can be commercialised successfully simply because they cannot freely steal the source code of a competing xGPL licensed software.

The real value of an FSF license, like the AGPL, is that it was designed to protect the copyright holders, and its users, "right to repair". And thus, it cannot be closed source by anyone (apart from the original copyright holders) once released under the said license (even if future versions are closed source, the old version under xPL remain opensource perpetually). Other open source license (that are less stringent) are prioritised to increase developer contribution. Source code under such license can be closed-source even from the original copyright holder.

But again, commercial success totally depends on the business model you come up with, irrespective of your license. The right license and the right business model will empower each other. Or cripple your business.

Stefan Tomanek - Creator of dietlibc, a libc optimized for small size - https://github.com/stefan-tomanek (The dietlibc project itself doesn't have an official GitHub repository, but you can find it at https://www.fefe.de/dietlibc/)

There are definitely some nice alternatives to glibc out there. He mentions Cosmopolitan Libc. I've used musl, uclibc, and dietlibc/libowfat in the past.

Maybe you should include the math part of a libc statically with your code. glibc is one option, or dietlibc if you want it to be as small as possible.

I agree that the implementation of printf is complex, but the interface is not. Hence calling it should not introduce bloat. Glibc adds a bunch of constructors and tables and such, whereas linking with dietlibc will probably lead to a smaller executable.

I am writing a short paper for school and the topic is Fast Inverse Square Root and alternatives. One of the questions is how the sqrt-function is implemented in glibc. Here is the code of that function.

The code isn't the easiest to read but in glibc it seems that the syscall is only performed if waiter are detected in userspace during an unlock operation

https://github.com/lattera/glibc/blob/master/nptl/pthread_mu...

You might still not realize, but floats are a large topic. Have a look at eg. this implementation here: https://github.com/lattera/glibc/blob/master/stdlib/strtod_l.c

This is a nice write up, thank you. However, I'm stilling interpreting this as a "fun trick" rather than the common sense method for solving the problem. For example, looking at the source code for htonl() from glibc: https://github.com/lattera/glibc/blob/master/inet/htonl.c

Second of all: The horrifying truth is that there is no such thing as a canonical text representation for IPv4 (source) (and yes... I am indeed citing the failed attempt to standardize this as my source for it not being standardized). Authoritatively speaking, all possible (non-binary) representations are equally invalid. In fact, text address resolution is typically delegated to the OS kernel, so what constitutes a "usable" address is liable to vary depending on if you're using Linux, OSX, Windows, or Other.

Optimized code gets really weird. The creators of strlen, for example, decided that iterating over each character to find the end was far too slow. So instead, they convert the character pointer into an int pointer and do bitwise manipulation with the int on two different magic numbers so they can check four/eight characters at once.

If you're using a cross-platform C compiler like gcc or clang, you're usually expected to switch to assembly. Here's the syscall instruction in glibc

Maybe you should include the math part of a libc statically with your code. glibc is one option, or dietlibc if you want it to be as small as possible.