Well, I do not use them at all. But I agree that this mechanism would avoid the additional copies. I have seen other single-header libraries though...

In any case, forcing me to figure out the specific XYZ_IMPLEMENTATION for each library is less user friendly that just proving a .c and .h file.

I actually agree with you that single-header libs are often not ideal. They're kind of neat in concept: just copy paste and done!

But after being burned a few times by naming or linking conflicts or you cloned your .c and forgot to remove the #define and now you have two implementations or having to debug any BSS/DATA/TEXT issues (because now lib and user code end up in the same .o and the linker can't do its magic for your esoteric architecture), I just took the habit of always manually creating a matching .c that only contains:

    #define BLAH_IMPLEMENTATION
    #include "blah.h"

Well for one you're able to easily use macros to customize features you want and don't want. Plus "forcing me to figure out the specific XYZ_IMPLEMENTATION" is a big of a weird compliant. You could say the same thing about linking a library. Besides, it's not hard to figure out and is usually one of the first lines of the file.

The single-header format also gives you MORE ways to compile the library and control which features to use or not use.