Home > OS >  Why not should you not include features.h?
Why not should you not include features.h?

Time:02-10

I was reading the linux features test macro page and in the NOTES section it states that:

<features.h> is a Linux/glibc-specific header file. Other systems have an analogous file, but typically with a different name. This header file is automatically included by other header files as required: it is not necessary to explicitly include it in order to employ feature test macros.

I understand that other systems wouldn't have the same filename as features.h, and therefore you shouldn't include it directly. But then, if you don't include the header file, how do you know if you can use the features test macros?

CodePudding user response:

glibc guarantees that #defines of the documented feature selection macros (_POSIX_C_SOURCE, _XOPEN_SOURCE, _GNU_SOURCE, etc) will be honored as long as they take effect before the first inclusion of any public C library header. For instance

/* file header comment */
#define _XOPEN_SOURCE 700 // first non-comment line of the file
#include <unistd.h>       // first #include in the file
// ... more code here ...

is guaranteed to make unistd.h declare things that are part of POSIX.1-2008 including XSI extensions.

The implementation of this guarantee involves features.h, but features.h is not a public C library header. Direct inclusion of features.h is not something you should ever need to do, and we (glibc devs) do not promise that this header will even continue to exist in the future. (For instance, a future release might merge it into bits/libc-header-start.h.)

  • Related