1

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?

Emile Cormier
  • 28,391
  • 15
  • 94
  • 122
CryptoBipto
  • 15
  • 2
  • I don't see how including or not including the header affects the use of the macros mentioned on the page. Could you give an example of what you think could be problematic? – user17732522 Feb 10 '22 at 00:53
  • exactly what macro do you want to use? – pm100 Feb 10 '22 at 00:53
  • You can always use feature test macros. The feature test macros are macros **you** define to tell the system headers which features you want them to declare. You do it by defining the macros you want with the values you want before including any headers. Then you just include headers as usual, such as `` or ``. E.g., if your program has `#define _BSD_SOURCE` and then includes ``, it is saying “I was written to use BSD features, so declare those.” Without `#define _BSD_SOURCE`, `` might omit some declarations. – Eric Postpischil Feb 10 '22 at 01:11

1 Answers1

5

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.)

zwol
  • 135,547
  • 38
  • 252
  • 361
  • `features.h` does _not_ admonish the user to "never include features.h directly", so it is [has been] a "public" file. To maintain backwards compatibility, it will always have to exist. If you wish, it could just do: `#include ` but the file needs to remain. _Side note:_ If you're a glibc dev, please kindly convey/upstream my rant re. `gettid`: https://stackoverflow.com/questions/61979901/gcc-warns-about-gettid-syscall-wrapper-with-glibc-2-30-8/61980001#61980001 – Craig Estey Feb 10 '22 at 03:44
  • (1) That's a historical oversight. It is not part of any standard and not part of the documented extensions. There is no guarantee it will continue to exist. (2) You can do that yourself, the mailing list [ libc-alpha@sourceware.org ] is open to the general public. `gettid` is not something I care about enough to start an argument on somebody else's behalf. – zwol Feb 10 '22 at 13:16