diff options
author | Roland McGrath <roland@gnu.org> | 1995-02-18 01:27:10 +0000 |
---|---|---|
committer | Roland McGrath <roland@gnu.org> | 1995-02-18 01:27:10 +0000 |
commit | 28f540f45bbacd939bfd07f213bcad2bf730b1bf (patch) | |
tree | 15f07c4c43d635959c6afee96bde71fb1b3614ee /manual/creature.texi | |
download | glibc-28f540f45bbacd939bfd07f213bcad2bf730b1bf.tar.gz glibc-28f540f45bbacd939bfd07f213bcad2bf730b1bf.tar.xz glibc-28f540f45bbacd939bfd07f213bcad2bf730b1bf.zip |
initial import
Diffstat (limited to 'manual/creature.texi')
-rw-r--r-- | manual/creature.texi | 113 |
1 files changed, 113 insertions, 0 deletions
diff --git a/manual/creature.texi b/manual/creature.texi new file mode 100644 index 0000000000..51bf53a0c2 --- /dev/null +++ b/manual/creature.texi @@ -0,0 +1,113 @@ +@node Feature Test Macros +@subsection Feature Test Macros + +@cindex feature test macros +The exact set of features available when you compile a source file +is controlled by which @dfn{feature test macros} you define. + +If you compile your programs using @samp{gcc -ansi}, you get only the +ANSI C library features, unless you explicitly request additional +features by defining one or more of the feature macros. +@xref{Invoking GCC,, GNU CC Command Options, gcc.info, The GNU CC Manual}, +for more information about GCC options.@refill + +You should define these macros by using @samp{#define} preprocessor +directives at the top of your source code files. These directives +@emph{must} come before any @code{#include} of a system header file. It +is best to make them the very first thing in the file, preceded only by +comments. You could also use the @samp{-D} option to GCC, but it's +better if you make the source files indicate their own meaning in a +self-contained way. + +@comment (none) +@comment POSIX.1 +@defvr Macro _POSIX_SOURCE +If you define this macro, then the functionality from the POSIX.1 +standard (IEEE Standard 1003.1) is available, as well as all of the +ANSI C facilities. +@end defvr + +@comment (none) +@comment POSIX.2 +@defvr Macro _POSIX_C_SOURCE +If you define this macro with a value of @code{1}, then the +functionality from the POSIX.1 standard (IEEE Standard 1003.1) is made +available. If you define this macro with a value of @code{2}, then both +the functionality from the POSIX.1 standard and the functionality from +the POSIX.2 standard (IEEE Standard 1003.2) are made available. This is +in addition to the ANSI C facilities. +@end defvr + +@comment (none) +@comment GNU +@defvr Macro _BSD_SOURCE +If you define this macro, functionality derived from 4.3 BSD Unix is +included as well as the ANSI C, POSIX.1, and POSIX.2 material. + +Some of the features derived from 4.3 BSD Unix conflict with the +corresponding features specified by the POSIX.1 standard. If this +macro is defined, the 4.3 BSD definitions take precedence over the +POSIX definitions. + +Due to the nature of some of the conflicts between 4.3 BSD and POSIX.1, +you need to use a special @dfn{BSD compatibility library} when linking +programs compiled for BSD compatibility. This is because some functions +must be defined in two different ways, one of them in the normal C +library, and one of them in the compatibility library. If your program +defines @code{_BSD_SOURCE}, you must give the option @samp{-lbsd-compat} +to the compiler or linker when linking the program, to tell it to find +functions in this special compatibility library before looking for them in +the normal C library. +@pindex -lbsd-compat +@pindex bsd-compat +@cindex BSD compatibility library. +@end defvr + +@comment (none) +@comment GNU +@defvr Macro _SVID_SOURCE +If you define this macro, functionality derived from SVID is +included as well as the ANSI C, POSIX.1, and POSIX.2 material. +@end defvr + +@comment (none) +@comment GNU +@defvr Macro _GNU_SOURCE +If you define this macro, everything is included: ANSI C, POSIX.1, +POSIX.2, BSD, SVID, and GNU extensions. In the cases where POSIX.1 +conflicts with BSD, the POSIX definitions take precedence. + +If you want to get the full effect of @code{_GNU_SOURCE} but make the +BSD definitions take precedence over the POSIX definitions, use this +sequence of definitions: + +@smallexample +#define _GNU_SOURCE +#define _BSD_SOURCE +#define _SVID_SOURCE +@end smallexample + +Note that if you do this, you must link your program with the BSD +compatibility library by passing the @samp{-lbsd-compat} option to the +compiler or linker. @strong{Note:} If you forget to do this, you may +get very strange errors at run time. +@end defvr + +We recommend you use @code{_GNU_SOURCE} in new programs. If you don't +specify the @samp{-ansi} option to GCC and don't define any of these macros +explicitly, the effect is the same as defining @code{_GNU_SOURCE}. + +When you define a feature test macro to request a larger class of features, +it is harmless to define in addition a feature test macro for a subset of +those features. For example, if you define @code{_POSIX_C_SOURCE}, then +defining @code{_POSIX_SOURCE} as well has no effect. Likewise, if you +define @code{_GNU_SOURCE}, then defining either @code{_POSIX_SOURCE} or +@code{_POSIX_C_SOURCE} or @code{_SVID_SOURCE} as well has no effect. + +Note, however, that the features of @code{_BSD_SOURCE} are not a subset of +any of the other feature test macros supported. This is because it defines +BSD features that take precedence over the POSIX features that are +requested by the other macros. For this reason, defining +@code{_BSD_SOURCE} in addition to the other feature test macros does have +an effect: it causes the BSD features to take priority over the conflicting +POSIX features. |