summaryrefslogtreecommitdiff
path: root/manual/creature.texi
diff options
context:
space:
mode:
authorRoland McGrath <roland@gnu.org>1995-02-18 01:27:10 +0000
committerRoland McGrath <roland@gnu.org>1995-02-18 01:27:10 +0000
commit28f540f45bbacd939bfd07f213bcad2bf730b1bf (patch)
tree15f07c4c43d635959c6afee96bde71fb1b3614ee /manual/creature.texi
initial import
Diffstat (limited to 'manual/creature.texi')
-rw-r--r--manual/creature.texi113
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.