Why is my stdbool.h not in /usr/include?

Question

I'm used to standard C header files being in /usr/include (e.g. stdio.h, stdlib.h, string.h, ctype.h and so on); yet - stdbool.h isn't. Now, I know it's newer than the rest, only being part of C99. But - I do have it, it's just at

/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdbool.h
/usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdbool.h
/usr/lib/gcc/x86_64-linux-gnu/5/include/stdbool.h

a different location for every GCC version. Why is that? It is, after all, a standard - it's not supposed to change from one GCC version to the next. And, sure enough, there aren't real differences between versions. (*) Why does is this one compiler-specific and the others system-wide?

_{* - Well, the copyright notice, and some ifdef based on a CPLUSPLUS version for when it's used with C++.}

Answer 1

It is, after all, a standard - it's not supposed to change from one GCC version to the next.

No, it is not a standard. The standard is that you can write

#include <stdbool.h>

in a translation unit and it will effect certain things. There's no guarantee from the language standards that headers are files, let alone that they are files in a particular directory in a filesystem on your computer with fixed contents.

The whole point of such standard headers is that they do whatever is appropriate to the C/C++ compiler to provide the things that the language standards say they should provide upon their inclusion. They provide the required declarations and macros (usually) using internal keywords, pragmas, macros, and intrinsics supplied by the compiler. This of course varies from compiler to compiler.

Which is the second error that you are making here. It is a myopic mistake to think that GCC is the only C/C++ compiler. People with older DOS or Win32 programming backgrounds, where there could be many compilers, will be very familiar with the idea that the standard headers are very much tied to the compiler. One cannot just take the standard headers from (say) Watcom C/C++ and use them with the Borland, Microsoft, IBM, or whatever C/C++ compilers.

That is the thinking to adopt, because this is true for you, too. Whilst what needs to be done in a standard header in order to achieve its purpose could potentially vary from one version of GCC to the next, they also can vary between (say) clang and GCC. Unix and Linux operating systems are not one-compiler monocultures.

And, indeed, you'll find float.h, limits.h, stdint.h, stddef.h, stdarg.h, and several other such standard headers all reside in these compiler-specific locations. limits.h is a particularly messy affair, because that encompasses both compiler-specific knowledge and target-platform-specific knowledge.

Further reading

• "4.1.2 Standard headers". Rationale for American National Standard for Information Systems — Programming Language — C.
• Bjarne Stroustrup (2013). "Standard Library Headers". The C++ Programming Language. 4th edition. Addison-Wesley. ISBN 9780133522853.
• Jonathan de Boyne Pollard (2012). Predefined macros in C/C++ that tell you what language features are available.. Frequently Given Answers.

Answer 2

On unix-like systems there is a distinction between the C compiler (normally gcc) and the C standard libary (normally glibc). Unlike many other operating systems the C standard library on unix-like systems also serves as the main OS-interfacing library.

Reading C standards won't help you here as they lump compiler and platform together as an "implementation".

Some headers "belong" to the C library as their purpose is to provide an interface to C library functionality. Those headers are installed by the C library and go in /usr/include .

Other headers "belong" to the C compiler as they describe compiler functionality. Since distributions typically support multiple C compilers these are placed in compiler-specific locations.