nbdkit VS glibc

This is correct, but doesn't quite explain why. It's because when you accept contributions from a variety of authors, without using a CLA, then your code base ends up with a patchwork of copyright, making relicensing practically impossible as you have to get buy-in from every author or else determine that author's contributions and remove/rewrite them.

GPL/LGPL are excellent licenses, but this patchwork of copyright can apply for any license you use. For a small project we wrote which was under BSD, we recently had to make a small (non-functional) change to the license, and we got buy-in from all the authors to do this which took quite a long time: https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...

Direct IO is very inflexible. A better way is this (recommended by Linus):

https://lkml.iu.edu/hypermail/linux/kernel/1005.2/01845.html

I implemented something along the same lines but a bit less spicy here:

https://gitlab.com/nbdkit/nbdkit/-/commit/aa5a2183a6d16afd91...

That second link is wrong, should be: https://gitlab.com/nbdkit/nbdkit/-/commit/a956e2e75d6c88eeef...

I think an exception might be made for a plain "C-like" struct that doesn't initialize members or contain anything except basic types. In the specific example[0] the code is actually surrounded by extern "C" { ... } so I suppose that the compiler "knows" this is a plain C struct?

[0] https://gitlab.com/nbdkit/nbdkit/-/blob/cd761c9bf770b23f678f...

We relicensed[1] a project which had 10 contributors, and we got every single one of them to do an Acked-by (by email) which took some weeks. That was the advice from our lawyers. Can't imagine the impossible hassle of doing the same for something like Linux.

[1] https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...

We use this (trick taken from stackoverflow) to make __COUNTER__ usefully provide unique names:

https://gitlab.com/nbdkit/nbdkit/-/blob/master/common/includ...

Example use:

https://gitlab.com/nbdkit/nbdkit/-/blob/master/common/includ...

I don't know what __EXP_COUNTER__ would add.

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

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.

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.

Here is the glibc version of the printf function source code. The definition of printf is on line 40 and appears to be an alias for __printf which is defined on line 27. __printf calls other functions (e.g. vfprintf ) which will call more lower level functions and so on.

ldblstrong_alias (_printf, printf); Got it from this

This also applies to C++ functions, like std::isspace.

Another fun one: With FD_CLR, FD_ISSET, FD_SET you can corrupt memory by merely passing a socket descriptor that is not 0..1024. Pass a negative integer for some undefined behavior as well (shift by negative value occurs here [1])

[1] https://github.com/lattera/glibc/blob/895ef79e04a953cac14938...