feature_test_macros(7)
โจ feature_test_macros โ the feature test macros glow-up โจ
okay bestie, welcome to the Miscellaneous Information Manual page for feature_test_macros(7), aka the thing that decides which definitions your system headers are even willing to show you ๐
๐ NAME ๐
feature_test_macros โ feature test macros. periodt.
๐ธ DESCRIPTION ๐ธ
Feature test macros let you, the programmer, control exactly which definitions get exposed by system header files when your program is compiled. it's giving you're the one holding the aux cord ๐ง
NOTE: for a feature test macro to actually do anything, it has to be defined before you include any header files. no cap. you can do it either in the compilation command (cc -DMACRO=value) or by defining the macro inside your source code before you include any headers.
and why the before-any-headers rule, you ask? because header files may freely include one another ๐ซ POSIX explicitly allows this. so like, look at this mess:
#include <abc.h>
#define _GNU_SOURCE
#include <xyz.h>
here, defining the _GNU_SOURCE macro may have no effect, because the header <abc.h> itself includes <xyz.h>. the macro showed up fashionably late to a party that already ended. sorry babe ๐ญ
so: some feature test macros are useful for creating portable applications, by preventing nonstandard definitions from being exposed. other macros are for the opposite vibe โ exposing nonstandard definitions that aren't exposed by default โจ
the precise effects of each of the feature test macros described below can be ascertained by inspecting the <features.h> header file. Note: applications do not need to directly include <features.h>; indeed, doing so is actively discouraged. See NOTES. ๐
๐ฆ Specification of feature test macro requirements in manual pages ๐ฆ
when a function requires that a feature test macro is defined, the manual page SYNOPSIS typically includes a note of the following form (this example is from the acct(2) manual page):
#include <unistd.h>
int acct(const char *filename);
Feature Test Macro Requirements for glibc (see
feature_test_macros(7)):
acct(): _BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)
the || means that in order to obtain the declaration of acct(2) from <unistd.h>, either of the following macro definitions must be made before including any header files:
#define _BSD_SOURCE
#define _XOPEN_SOURCE /* or any value < 500 */
alternatively, equivalent definitions can be included in the compilation command:
cc -D_BSD_SOURCE
cc -D_XOPEN_SOURCE # Or any value < 500
and note that, as described below, some feature test macros are defined by default ๐ so it may not always be necessary to explicitly specify the feature test macro(s) shown in the SYNOPSIS. sometimes the defaults already had your back, bestie.
in a few cases, manual pages use a shorthand for expressing the feature test macro requirements (this example from readahead(2)):
#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#include <fcntl.h>
ssize_t readahead(int fd, off_t *offset, size_t count);
this format is employed when the feature test macros ensure that the proper function declarations are visible, and the macros are not defined by default. iykyk ๐
๐ Feature test macros understood by glibc ๐
the paragraphs below explain how feature test macros are handled in glibc 2.x, x > 0.
first, though, a summary of a few details for the impatient ๐ซถ:
- the macros that you most likely need to use in modern source code are
_POSIX_C_SOURCE(for definitions from various versions of POSIX.1),_XOPEN_SOURCE(for definitions from various versions of SUS),_GNU_SOURCE(for GNU and/or Linux specific stuff), and_DEFAULT_SOURCE(to get definitions that would normally be provided by default). - certain macros are defined with default values. thus, although one or more macros may be indicated as being required in the SYNOPSIS of a man page, it may not be necessary to define them explicitly. full details of the defaults are given later in this man page. (stay tuned, we're not there yet ๐)
glibc understands the following feature test macros:
__STRICT_ANSI__โ ISO Standard C. this macro is implicitly defined bygcc(1)when invoked with, for example, the-std=c99or-ansiflag. it just appears. iconic behavior tbh._POSIX_C_SOURCEโ defining this macro causes header files to expose definitions conforming to the following standards, depending on the value. slay, it's value-dependent:>= 1โ POSIX.1-1990. POSIX.1-1990 implies ISO C90.>= 2โ POSIX.2-1992.>= 199309Lโ POSIX.1b (real-time extensions).199506L(since glibc 2.1) โ POSIX.1c (threads).200112L(since glibc 2.3.3) โ POSIX.1-2001 (excluding the XSI extension). POSIX.1-2001 implies ISO C99.200809L(since glibc 2.10) โ POSIX.1-2008 (excluding the XSI extension). POSIX.1-2008 implies ISO C99.
_POSIX_SOURCE[[deprecated]]โ equivalent to-D_POSIX_C_SOURCE=1. that's it, that's the whole macro. retired queen, do not use ๐ชฆ_XOPEN_SOURCEโ defining this macro causes header files to expose definitions conforming to the following standards, depending on the value:1โ POSIX.1, POSIX.2, XPG4.500โ SUSv2 (Issue 5).600(since glibc 2.2) โ SUSv3 (Issue 6). SUSv3 is POSIX.1-2001 plus the XSI extension.700(since glibc 2.10) โ SUSv4 (Issue 7). SUSv4 is POSIX.1-2008 plus the XSI extension.
_XOPEN_SOURCE_EXTENDED[[deprecated]]โ defining this macro causes header files to expose definitions conforming to SUSv1. past its prime, bestie ๐_ISOCxx_SOURCEโ defining one of these macros causes header files to expose definitions conforming to the corresponding version of the ISO C standard.
they should not be defined by programmers. instead, the language version should be specified with the corresponding compiler flag. we don't do this by hand, ok? let the compiler cook ๐ฅ
_ISOC99_SOURCE(since glibc 2.1.3) โ C99. use-std=c99or-std=gnu99instead._ISOC11_SOURCE(since glibc 2.16) โ C11. use-std=c11or-std=gnu11instead._ISOC23_SOURCE(since glibc 2.40)_ISOC2X_SOURCE(since glibc 2.31)[[deprecated]]โ C23. use-std=c23or-std=gnu23instead. exposes declarations consistent with the ISO C23 standard.
_LARGEFILE64_SOURCE[[deprecated]]โ expose definitions for the alternative API specified by the LFS (Large File Summit) as a "transitional extension" to the Single UNIX Specification. (Seehttp://opengroup.org/platform/lfs.html.) the alternative API consists of a set of new objects (i.e., functions and types) whose names are suffixed with"64"(e.g.,off64_tversusoff_t,lseek64()versuslseek(), etc.). new programs should not employ this macro; instead_FILE_OFFSET_BITS=64should be employed. we said what we said ๐_LARGEFILE_SOURCE[[deprecated]]โ this macro was historically used to expose certain functions (specifically,fseeko(3)andftello(3)) that address limitations of earlier APIs (fseek(3)andftell(3)) that uselongfor file offsets. these functions are now part of SUSv2; use_XOPEN_SOURCEinstead. alternatively, defining_FILE_OFFSET_BITSwith the value64also serves for this. vintage, but the upgrade is right there ๐ฆ_FILE_OFFSET_BITSโ defining this macro with the value64automatically converts references to 32-bit functions and data types related to file I/O and filesystem operations into references to their 64-bit counterparts. this is useful for performing I/O on large files (> 2 Gigabytes) on 32-bit systems. it is also useful when calling functions likecopy_file_range(2)that were added more recently and that come only in 64-bit flavors. (defining this macro permits correctly written programs to use large files with only a recompilation being required.) no code rewrite, just recompile and glow up โจ- 64-bit systems naturally permit file sizes greater than 2 Gigabytes, and on those systems this macro has no effect. sorry, nothing to see here ๐
_TIME_BITSโ defining this macro with the value64changes the width oftime_t(3type)to 64-bit which allows handling of timestamps beyond 2038. it is closely related to_FILE_OFFSET_BITSand depending on implementation, may require it set. this macro is available as of glibc 2.34. future-proofing your timestamps, 2038 who? ๐ฐ๏ธ๐_BSD_SOURCE[[deprecated]]โ defining this macro with any value causes header files to expose BSD-derived definitions.- in glibc versions up to and including 2.18, defining this macro also causes BSD definitions to be preferred in some situations where standards conflict, unless one or more of
_SVID_SOURCE,_POSIX_SOURCE,_POSIX_C_SOURCE,_XOPEN_SOURCE,_XOPEN_SOURCE_EXTENDED, or_GNU_SOURCEis defined, in which case BSD definitions are disfavored. since glibc 2.19,_BSD_SOURCEno longer causes BSD definitions to be preferred in case of conflicts. - since glibc 2.20, this macro is deprecated. it now has the same effect as defining
_DEFAULT_SOURCE, but generates a compile-time warning (unless_DEFAULT_SOURCEis also defined). use_DEFAULT_SOURCEinstead. to allow code that requires_BSD_SOURCEin glibc 2.19 and earlier and_DEFAULT_SOURCEin glibc 2.20 and later to compile without warnings, define both_BSD_SOURCEand_DEFAULT_SOURCE. yes both. it's a situationship ๐
- in glibc versions up to and including 2.18, defining this macro also causes BSD definitions to be preferred in some situations where standards conflict, unless one or more of
_SVID_SOURCE[[deprecated]]โ defining this macro with any value causes header files to expose System V-derived definitions. (SVID == System V Interface Definition; seestandards(7).)- since glibc 2.20, this macro is deprecated in the same fashion as
_BSD_SOURCE. same retirement party, same dress code ๐
- since glibc 2.20, this macro is deprecated in the same fashion as
_DEFAULT_SOURCE(since glibc 2.19) โ this macro can be defined to ensure that the "default" definitions are provided even when the defaults would otherwise be disabled, as happens when individual macros are explicitly defined, or the compiler is invoked in one of its "standard" modes (e.g.,cc -std=c99). defining_DEFAULT_SOURCEwithout defining other individual macros or invoking the compiler in one of its "standard" modes has no effect. it's the bring-back-the-vibes macro ๐ซถ- the "default" definitions comprise those required by POSIX.1-2008 and ISO C99, as well as various definitions originally derived from BSD and System V. on glibc 2.19 and earlier, these defaults were approximately equivalent to explicitly defining the following:
cc -D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809
_ATFILE_SOURCE(since glibc 2.4) โ defining this macro with any value causes header files to expose declarations of a range of functions with the suffix"at"; seeopenat(2). since glibc 2.10, this macro is also implicitly defined if_POSIX_C_SOURCEis defined with a value greater than or equal to200809L. the*at()girlies stay winning ๐_GNU_SOURCEโ bestie. the moment. ๐ defining this macro (like, with any value, don't overthink it) implicitly defines_ATFILE_SOURCE,_LARGEFILE64_SOURCE,_ISOC99_SOURCE,_XOPEN_SOURCE_EXTENDED,_POSIX_SOURCE,_POSIX_C_SOURCEwith the value200809L(200112Lbefore glibc 2.10;199506Lbefore glibc 2.5;199309Lbefore glibc 2.1) and_XOPEN_SOURCEwith the value700(600before glibc 2.10;500before glibc 2.2). plus, extra โจ, various GNU-specific extensions are also exposed. it's giving everything, all at once.
since glibc 2.19, defining _GNU_SOURCE also has the effect of implicitly defining _DEFAULT_SOURCE. before glibc 2.20, defining _GNU_SOURCE also had the effect of implicitly defining _BSD_SOURCE and _SVID_SOURCE too. ๐ซถ
_REENTRANT(deprecated) ๐ฅฒ โ okay so historically, on various C libraries it was necessary to define this macro in all multithreaded code. (some C libraries may still require this, no cap.) in glibc, this macro also exposed definitions of certain reentrant functions.
but here's the tea โ glibc has been thread-safe by default for many years now; since glibc 2.3, the only effect of defining _REENTRANT has been to enable one or two of the same declarations that are also enabled by defining _POSIX_C_SOURCE with a value of 199506L or greater.
_REENTRANT is now obsolete. in glibc 2.25 and later, defining _REENTRANT is equivalent to defining _POSIX_C_SOURCE with the value 199506L. if a higher POSIX conformance level is selected by any other means (such as _POSIX_C_SOURCE itself, _XOPEN_SOURCE, _DEFAULT_SOURCE, or _GNU_SOURCE), then defining _REENTRANT has no effect. ๐
this macro is automatically defined if one compiles with cc -pthread.
_THREAD_SAFE(deprecated) โ literally just a synonym for_REENTRANT, provided for compatibility with some other implementations. the way that's the whole description ๐ญ_FORTIFY_SOURCE(since glibc 2.3.4) โ defining this macro causes some lightweight checks to be performed to detect some buffer overflow errors when employing various string and memory manipulation functions (for example,memcpy(3),memset(3),stpcpy(3),strcpy(3),strncpy(3),strcat(3),strncat(3),sprintf(3),snprintf(3),vsprintf(3),vsnprintf(3),gets(3), and wide character variants thereof). for some functions, argument consistency is checked; for example, a check is made thatopen(2)has been supplied with a mode argument when the specified flags includeO_CREAT. not all problems are detected, just some common cases. ๐คทโ๏ธ- if
_FORTIFY_SOURCEis set to1, with compiler optimization level 1 (gcc -O1) and above, checks that shouldn't change the behavior of conforming programs are performed. - with
_FORTIFY_SOURCEset to2, some more checking is added, but some conforming programs might fail. ๐ - some of the checks can be performed at compile time (via macros logic implemented in header files), and result in compiler warnings; other checks take place at run time, and result in a run-time error if the check fails.
- with
_FORTIFY_SOURCEset to3, additional checking is added to intercept some function calls used with an argument of variable size where the compiler can deduce an upper bound for its value. for example, a program wheremalloc(3)'s size argument is variable can now be fortified. ๐ฅ
- if
use of this macro requires compiler support, available since gcc 4.0 and clang 2.6. use of _FORTIFY_SOURCE set to 3 requires gcc 12.0 or later, or clang 9.0 or later, in conjunction with glibc 2.33 or later.
๐ธ Default definitions, implicit definitions, and combining definitions ๐ธ
if no feature test macros are explicitly defined, then the following feature test macros are defined by default: _BSD_SOURCE (in glibc 2.19 and earlier), _SVID_SOURCE (in glibc 2.19 and earlier), _DEFAULT_SOURCE (since glibc 2.19), _POSIX_SOURCE, and _POSIX_C_SOURCE=200809L (200112L before glibc 2.10; 199506L before glibc 2.4; 199309L before glibc 2.1). okay default queen behavior ๐
if any of __STRICT_ANSI__, _ISOC99_SOURCE, _ISOC11_SOURCE (since glibc 2.18), _ISOC23_SOURCE (since glibc 2.40), _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED (in glibc 2.11 and earlier), _BSD_SOURCE (in glibc 2.19 and earlier), or _SVID_SOURCE (in glibc 2.19 and earlier) is explicitly defined, then _BSD_SOURCE, _SVID_SOURCE, and _DEFAULT_SOURCE are not defined by default.
๐ STANDARDS ๐
POSIX.1 specifies _POSIX_C_SOURCE, _POSIX_SOURCE, and _XOPEN_SOURCE.
_FILE_OFFSET_BITS is not specified by any standard, but is employed on some other implementations.
_BSD_SOURCE, _SVID_SOURCE, _DEFAULT_SOURCE, _ATFILE_SOURCE, _GNU_SOURCE, _FORTIFY_SOURCE, _REENTRANT, and _THREAD_SAFE are specific to glibc. glibc main character energy only โจ
๐ฆ HISTORY ๐ฆ
_XOPEN_SOURCE_EXTENDED was specified by XPG4v2 (aka SUSv1), but is not present in SUSv2 and later. rip to a real one, gone but not forgotten ๐ฅ
๐ NOTES ๐
<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. she includes herself, she's independent ๐โ๏ธ
according to which of the above feature test macros are defined, <features.h> internally defines various other macros that are checked by other glibc header files. these macros have names prefixed by two underscores (e.g., __USE_MISC). programs should never define these macros directly: instead, the appropriate feature test macro(s) from the list above should be employed.
bestie do NOT touch the__macros. that's not your business, that's<features.h>'s business. ๐ โ๏ธ
๐ EXAMPLES ๐
the program below can be used to explore how the various feature test macros are set depending on the glibc version and what feature test macros are explicitly set. the following shell session, on a system with glibc 2.10, shows some examples of what we would see:
$ cc ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 200809L
_BSD_SOURCE defined
_SVID_SOURCE defined
_ATFILE_SOURCE defined
$ cc -D_XOPEN_SOURCE=500 ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 199506L
_XOPEN_SOURCE defined: 500
$ cc -D_GNU_SOURCE ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 200809L
_ISOC99_SOURCE defined
_XOPEN_SOURCE defined: 700
_XOPEN_SOURCE_EXTENDED defined
_LARGEFILE64_SOURCE defined
_BSD_SOURCE defined
_SVID_SOURCE defined
_ATFILE_SOURCE defined
_GNU_SOURCE defined
๐ง Program source ๐ง
/* ftm.c */
#include <stdint.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
#ifdef _POSIX_SOURCE
printf("_POSIX_SOURCE defined\n");
#endif
#ifdef _POSIX_C_SOURCE
printf("_POSIX_C_SOURCE defined: %jdL\n",
(intmax_t) _POSIX_C_SOURCE);
#endif
#ifdef _ISOC99_SOURCE
printf("_ISOC99_SOURCE defined\n");
#endif
#ifdef _ISOC11_SOURCE
printf("_ISOC11_SOURCE defined\n");
#endif
#ifdef _ISOC23_SOURCE
printf("_ISOC23_SOURCE defined\n");
#endif
#ifdef _XOPEN_SOURCE
printf("_XOPEN_SOURCE defined: %d\n", _XOPEN_SOURCE);
#endif
#ifdef _XOPEN_SOURCE_EXTENDED
printf("_XOPEN_SOURCE_EXTENDED defined\n");
#endif
#ifdef _LARGEFILE64_SOURCE
printf("_LARGEFILE64_SOURCE defined\n");
#endif
#ifdef _FILE_OFFSET_BITS
printf("_FILE_OFFSET_BITS defined: %d\n", _FILE_OFFSET_BITS);
#endif
#ifdef _TIME_BITS
printf("_TIME_BITS defined: %d\n", _TIME_BITS);
#endif
#ifdef _BSD_SOURCE
printf("_BSD_SOURCE defined\n");
#endif
#ifdef _SVID_SOURCE
printf("_SVID_SOURCE defined\n");
#endif
#ifdef _DEFAULT_SOURCE
printf("_DEFAULT_SOURCE defined\n");
#endif
#ifdef _ATFILE_SOURCE
printf("_ATFILE_SOURCE defined\n");
#endif
#ifdef _GNU_SOURCE
printf("_GNU_SOURCE defined\n");
#endif
#ifdef _REENTRANT
printf("_REENTRANT defined\n");
#endif
#ifdef _THREAD_SAFE
printf("_THREAD_SAFE defined\n");
#endif
#ifdef _FORTIFY_SOURCE
printf("_FORTIFY_SOURCE defined\n");
#endif
exit(EXIT_SUCCESS);
}
compile it, run it, watch the macros spill out like a little fortune teller telling you your feature set ๐ฎ
๐ SEE ALSO ๐
libc(7)standards(7)system_data_types(7)- the section "Feature Test Macros" under
info libc. /usr/include/features.h
and that's a wrap bestie!! ๐ซถ this lil guide is straight from Linux man-pages 6.20, dated 2026-06-24, and it's the feature_test_macros(7) girlies' bible. go forth and define responsibly, mwah ๐โจ
๐ฆ where this page comes from
- arch rolling: man-pages 6.20-1 ยท BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
- nixpkgs unstable: man-pages 6.20
- ๐ the page's license: Linux-man-pages-copyleft
- Copyright 2006, Michael Kerrisk <mtk.manpages@gmail.com>
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms