> You'll find that a fair amount of single-header C libraries that are explicitly C89-supporting are in use by game developers.
Is that true? I thought low-level game development was almost entirely in C++. Why is there resistance to using libraries written in the same language as the rest of the program?
C libraries are usually easier to integrate even into C++ projects because there's no "C++ subset incompatibility" (e.g. use of exceptions, RTTI, banned stdlib features etc... - since most of those things don't exist in C in the first place), and "flat" C-APIs are also usually much saner (some C++ library APIs have designed themselves into class-hierarchy- and/or template-hell).
There are easy to integrate C++ libraries like Dear ImGui but they are in the minority, and (for instance) Dear ImGui uses a very restricted set of C++ features (it's essentially "C with namespaces and overloading", so it's not very far removed from a C library).
It's true that C is not a subset of C++, but in reality such implementation details don't matter much as long as the library API is both C and C++ compatible. Compiling a C source file in a C++ project is as simple as using a ".c" file extension, build systems will then compile the file in "C mode" instead of "C++ mode".
It's an STB-style single-file library, which means the implementation is in a separate ifdef-block from the interface declarations, this allows to compile the implementation in a different source file (which can be a C file) from the source files which use the library (which can be C++ files).
Here's for example such an "implementation source file" example (using stb_image.h):
Lots of legacy targets have shoddy-at-best C99, or new, support.
You'll find that a fair amount of single-header C libraries that are explicitly C89-supporting are in use by game developers.