\input texinfo
@setfilename cpp.info
@settitle The C Preprocessor
-
-@ifinfo
-@dircategory Programming
-@direntry
-* Cpp: (cpp). The GNU C preprocessor.
-@end direntry
-@end ifinfo
-
+@setchapternewpage off
@c @smallbook
@c @cropmarks
@c @finalout
-@setchapternewpage odd
-@ifinfo
-This file documents the GNU C Preprocessor.
-Copyright 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001 Free Software Foundation, Inc.
+@macro copyrightnotice
+@c man begin COPYRIGHT
+Copyright @copyright{} 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996,
+1997, 1998, 1999, 2000, 2001
+Free Software Foundation, Inc.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.1 or
+any later version published by the Free Software Foundation. A copy of
+the license is included in the accompanying manual for GNU CC, in the
+section ``GNU Free Documentation License''.
+@c man end
+@end macro
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
+@c The manpage doesn't have Front-Cover and Back-Cover Texts, but the
+@c complete manual does. -zw
@ignore
-Permission is granted to process this file through Tex and print the
-results, provided the printed document carries copying permission
-notice identical to this one except for the removal of this paragraph
-(this paragraph not being relevant to the printed manual).
-
+@c man begin COPYRIGHT
+This manual contains no Invariant Sections, and has no Front-Cover Texts
+or Back-Cover Texts.
+@c man end
@end ignore
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that
-the entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions.
+@macro covertexts
+This manual contains no Invariant Sections. The Front-Cover Texts are
+(a) (see below), and the the Back-Cover Texts are (b) (see below).
+
+(a) The FSF's Front-Cover Text is:
+
+ A GNU Manual
+
+(b) The FSF's Back-Cover Text is:
+
+ You have freedom to copy and modify this GNU Manual, like GNU
+ software. Copies published by the Free Software Foundation raise
+ funds for GNU development.
+@end macro
+
+@c Better form for references to other manuals.
+@ifinfo
+@macro docref{docname}
+GNU \docname\. @ref{Top, \docname\, , \docname\}@c
+@end macro
+@end ifinfo
+@ifnotinfo
+@macro docref{docname}
+GNU \docname\@c
+@end macro
+@end ifnotinfo
+
+@ifinfo
+@dircategory Programming
+@direntry
+* Cpp: (cpp). The GNU C preprocessor.
+@end direntry
@end ifinfo
@titlepage
-@c @finalout
@title The C Preprocessor
-@subtitle Last revised January 2001
+@subtitle Last revised April 2001
@subtitle for GCC version 3
@author Richard M. Stallman
+@author Zachary Weinberg
@page
-@vskip 2pc
-This booklet is eventually intended to form the first chapter of a GNU
-C Language manual.
-
+@c There is a fill at the bottom of the page, so we need a filll to
+@c override it.
@vskip 0pt plus 1filll
-@c man begin COPYRIGHT
-Copyright @copyright{} 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996,
-1997, 1998, 1999, 2000, 2001
-Free Software Foundation, Inc.
-
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that
-the entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions.
-@c man end
+@copyrightnotice{}
+@covertexts{}
@end titlepage
@contents
@page
-@node Top, Global Actions,, (DIR)
-@chapter The C Preprocessor
-@c man begin DESCRIPTION
-
-The C preprocessor is a @dfn{macro processor} that is used automatically
-by the C compiler to transform your program before actual compilation.
-It is called a macro processor because it allows you to define
-@dfn{macros}, which are brief abbreviations for longer constructs.
+@ifinfo
+@node Top
+@top
+The C preprocessor implements the macro language used to transform C,
+C++, and Objective C programs before they are compiled. It can also be
+useful on its own.
-The C preprocessor is intended only for macro processing of C, C++ and
-Objective C source files. For macro processing of other files, you are
-strongly encouraged to use alternatives like M4, which will likely give
-you better results and avoid many problems. For example, normally the C
-preprocessor does not preserve arbitrary whitespace verbatim, but
-instead replaces each sequence with a single space.
+@menu
+* Overview::
+* Header Files::
+* Macros::
+* Conditionals::
+* Diagnostics::
+* Line Control::
+* Pragmas::
+* Other Directives::
+* Preprocessor Output::
+* Traditional Mode::
+* Implementation Details::
+* Invocation::
+* Index of Directives::
+* Concept Index::
+
+@detailmenu
+ --- The Detailed Node Listing ---
+
+Overview
+
+* Initial processing::
+* Tokenization::
+* The preprocessing language::
+
+Header Files
+
+* Include Syntax::
+* Include Operation::
+* Search Path::
+* Once-Only Headers::
+* Computed Includes::
+* Wrapper Headers::
+* System Headers::
+
+Macros
+
+* Object-like Macros::
+* Function-like Macros::
+* Macro Arguments::
+* Stringification::
+* Concatenation::
+* Variadic Macros::
+* Predefined Macros::
+* Undefining and Redefining Macros::
+* Macro Pitfalls::
+
+Predefined Macros
+
+* Standard Predefined Macros::
+* Common Predefined Macros::
+* System-specific Predefined Macros::
+* C++ Named Operators::
+
+Macro Pitfalls
+
+* Misnesting::
+* Operator Precedence Problems::
+* Swallowing the Semicolon::
+* Duplication of Side Effects::
+* Self-Referential Macros::
+* Argument Prescan::
+* Newlines in Arguments::
+
+Conditionals
+
+* Conditional Uses::
+* Conditional Syntax::
+* Deleted Code::
+
+Conditional Syntax
+
+* Ifdef::
+* If::
+* Defined::
+* Else::
+* Elif::
+
+Implementation Details
+
+* Implementation-defined behavior::
+* Implementation limits::
+* Obsolete Features::
+* Differences from previous versions::
+
+Obsolete Features
+
+* Assertions::
+* Obsolete once-only headers::
+* Miscellaneous obsolete features::
+
+@end detailmenu
+@end menu
-For use on C-like source files, the C preprocessor provides four
-separate facilities that you can use as you see fit:
+@copyrightnotice{}
+@covertexts{}
+@end ifinfo
-@itemize @bullet
-@item
-Inclusion of header files. These are files of declarations that can be
-substituted into your program.
+@node Overview
+@chapter Overview
+@c man begin DESCRIPTION
+The C preprocessor, often known as @dfn{cpp}, is a @dfn{macro processor}
+that is used automatically by the C compiler to transform your program
+before compilation. It is called a macro processor because it allows
+you to define @dfn{macros}, which are brief abbreviations for longer
+constructs.
-@item
-Macro expansion. You can define @dfn{macros}, which are abbreviations
-for arbitrary fragments of C code, and then the C preprocessor will
-replace the macros with their definitions throughout the program.
+The C preprocessor is intended to be used only with C, C++, and
+Objective C source code. In the past, it has been abused as a general
+text processor. It will choke on input which does not obey C's lexical
+rules. For example, apostrophes will be interpreted as the beginning of
+character constants, and cause errors. Also, you cannot rely on it
+preserving characteristics of the input which are not significant to
+C-family languages. If a Makefile is preprocessed, all the hard tabs
+will be removed, and the Makefile will not work.
-@item
-Conditional compilation. Using special preprocessing directives, you
-can include or exclude parts of the program according to various
-conditions.
+Having said that, you can often get away with using cpp on things which
+are not C. Other Algol-ish programming languages are often safe
+(Pascal, Ada, etc.) So is assembly, with caution. @option{-traditional}
+mode preserves more white space, and is otherwise more permissive. Many
+of the problems can be avoided by writing C or C++ style comments
+instead of native language comments, and keeping macros simple.
-@item
-Line control. If you use a program to combine or rearrange source files
-into an intermediate file which is then compiled, you can use line
-control to inform the compiler of where each source line originally came
-from.
-@end itemize
+Wherever possible, you should use a preprocessor geared to the language
+you are writing in. Modern versions of the GNU assembler have macro
+facilities. Most high level programming languages have their own
+conditional compilation and inclusion mechanism. If all else fails,
+try a true general text processor, such as @docref{M4}.
C preprocessors vary in some details. This manual discusses the GNU C
preprocessor, which provides a small superset of the features of ISO
-Standard C@.
-
-In its default mode, the GNU C preprocessor does not do a few things
-required by the standard. These are features which are rarely, if ever,
-used, and may cause surprising changes to the meaning of a program which
-does not expect them. To get strict ISO Standard C, you should use the
-@samp{-std=c89} or @samp{-std=c99} options, depending on which version
-of the standard you want. To get all the mandatory diagnostics, you
-must also use @samp{-pedantic}. @xref{Invocation}.
-
+Standard C@. In its default mode, the GNU C preprocessor does not do a
+few things required by the standard. These are features which are
+rarely, if ever, used, and may cause surprising changes to the meaning
+of a program which does not expect them. To get strict ISO Standard C,
+you should use the @option{-std=c89} or @option{-std=c99} options, depending
+on which version of the standard you want. To get all the mandatory
+diagnostics, you must also use @option{-pedantic}. @xref{Invocation}.
@c man end
@menu
-* Global Actions:: Actions made uniformly on all input files.
-* Directives:: General syntax of preprocessing directives.
-* Header Files:: How and why to use header files.
-* Macros:: How and why to use macros.
-* Conditionals:: How and why to use conditionals.
-* Assertions:: How and why to use assertions.
-* Line Control:: Use of line control when you combine source files.
-* Other Directives:: Miscellaneous preprocessing directives.
-* Output:: Format of output from the C preprocessor.
-* Implementation:: Implementation limits and behavior.
-* Unreliable Features:: Undefined behavior and deprecated features.
-* Invocation:: How to invoke the preprocessor; command options.
-* Concept Index:: Index of concepts and terms.
-* Index:: Index of directives, predefined macros and options.
+* Initial processing::
+* Tokenization::
+* The preprocessing language::
@end menu
-@node Global Actions, Directives, Top, Top
-@section Transformations Made Globally
-@cindex ASCII NUL handling
+@node Initial processing
+@section Initial processing
-Most C preprocessor features are inactive unless you give specific
-directives to request their use. (Preprocessing directives are lines
-starting with a @samp{#} token, possibly preceded by whitespace;
-@pxref{Directives}). However, there are four transformations that the
-preprocessor always makes on all the input it receives, even in the
-absence of directives. These are, in order:
+The preprocessor performs a series of textual transformations on its
+input. These happen before all other processing. Conceptually, they
+happen in a rigid order, and the entire file is run through each
+transformation before the next one begins. GNU CPP actually does them
+all at once, for performance reasons. These transformations correspond
+roughly to the first three ``phases of translation'' described in the C
+standard.
@enumerate
@item
-Trigraphs, if enabled, are replaced with the character they represent.
+@cindex character sets
+@cindex line endings
+The input file is read into memory and broken into lines.
+
+GNU CPP expects its input to be a text file, that is, an unstructured
+stream of ASCII characters, with some characters indicating the end of a
+line of text. Extended ASCII character sets, such as ISO Latin-1 or
+Unicode encoded in UTF-8, are also acceptable. Character sets that are
+not strict supersets of seven-bit ASCII will not work. We plan to add
+complete support for international character sets in a future release.
+
+Different systems use different conventions to indicate the end of a
+line. GCC accepts the ASCII control sequences @kbd{LF}, @kbd{@w{CR
+LF}}, @kbd{CR}, and @kbd{@w{LF CR}} as end-of-line markers. The first
+three are the canonical sequences used by Unix, DOS and VMS, and the
+classic Mac OS (before OSX) respectively. You may therefore safely copy
+source code written on any of those systems to a different one and use
+it without conversion. (GCC may lose track of the current line number
+if a file doesn't consistently use one convention, as sometimes happens
+when it is edited on computers with different conventions that share a
+network file system.) @kbd{@w{LF CR}} is included because it has been
+reported as an end-of-line marker under exotic conditions.
+
+If the last line of any input file lacks an end-of-line marker, the end
+of the file is considered to implicitly supply one. The C standard says
+that this condition provokes undefined behavior, so GCC will emit a
+warning message.
@item
-Backslash-newline sequences are deleted, no matter where. This
-feature allows you to break long lines for cosmetic purposes without
-changing their meaning.
-
-Recently, the non-traditional preprocessor has relaxed its treatment of
-escaped newlines. Previously, the newline had to immediately follow a
-backslash. The current implementation allows whitespace in the form of
-spaces, horizontal and vertical tabs, and form feeds between the
-backslash and the subsequent newline. The preprocessor issues a
-warning, but treats it as a valid escaped newline and combines the two
-lines to form a single logical line. This works within comments and
-tokens, as well as between tokens. Comments are @emph{not} treated as
-whitespace for the purposes of this relaxation, since they have not yet
-been replaced with spaces.
+@cindex trigraphs
+If trigraphs are enabled, they are replaced by their corresponding
+single characters.
+
+These are nine three-character sequences, all starting with @samp{??},
+that are defined by ISO C to stand for single characters. They permit
+obsolete systems that lack some of C's punctuation to use C. For
+example, @samp{??/} stands for @samp{\}, so @t{'??/n'} is a character
+constant for a newline. By default, GCC ignores trigraphs, but if you
+request a strictly conforming mode with the @option{-std} option, then
+it converts them.
+
+Trigraphs are not popular and many compilers implement them incorrectly.
+Portable code should not rely on trigraphs being either converted or
+ignored. If you use the @option{-Wall} or @option{-Wtrigraphs} options,
+GCC will warn you when a trigraph would change the meaning of your
+program if it were converted.
+
+In a string constant, you can prevent a sequence of question marks from
+being confused with a trigraph by inserting a backslash between the
+question marks. @t{"(??\?)"} is the string @samp{(???)}, not
+@samp{(?]}. Traditional C compilers do not recognize this idiom.
+
+The nine trigraphs and their replacements are
+
+@example
+Trigraph: ??( ??) ??< ??> ??= ??/ ??' ??! ??-
+Replacement: [ ] @{ @} # \ ^ | ~
+@end example
@item
-All comments are replaced with single spaces.
+@cindex continued lines
+@cindex backslash-newline
+Continued lines are merged into one long line.
+
+A continued line is a line which ends with a backslash, @samp{\}. The
+backslash is removed and the following line is joined with the current
+one. No space is inserted, so you may split a line anywhere, even in
+the middle of a word. (It is generally more readable to split lines
+only at white space.)
+
+The trailing backslash on a continued line is commonly referred to as a
+@dfn{backslash-newline}.
+
+If there is white space between a backslash and the end of a line, that
+is still a continued line. However, as this is usually the result of an
+editing mistake, and many compilers will not accept it as a continued
+line, GCC will warn you about it.
@item
-Predefined macro names are replaced with their expansions
-(@pxref{Predefined}).
-@end enumerate
+@cindex comments
+@cindex line comments
+@cindex block comments
+All comments are replaced with single spaces.
+
+There are two kinds of comments. @dfn{Block comments} begin with
+@samp{/*} and continue until the next @samp{*/}. Block comments do not
+nest:
+
+@example
+/* @r{this is} /* @r{one comment} */ @r{text outside comment}
+@end example
+
+@dfn{Line comments} begin with @samp{//} and continue to the end of the
+current line. Line comments do not nest either, but it does not matter,
+because they would end in the same place anyway.
+
+@example
+// @r{this is} // @r{one comment}
+@r{text outside comment}
+@end example
+
+It is safe to put line comments inside block comments, or vice versa.
+
+@example
+@group
+/* @r{block comment}
+ // @r{contains line comment}
+ @r{yet more comment}
+ */ @r{outside comment}
+
+// @r{line comment} /* @r{contains block comment} */
+@end group
+@end example
+
+But beware of commenting out one end of a block comment with a line
+comment.
+
+@example
+@group
+ // @r{l.c.} /* @r{block comment begins}
+ @r{oops! this isn't a comment anymore} */
+@end group
+@end example
+
+Comments are not recognized within string literals. @t{@w{"/* blah
+*/"}} is the string constant @samp{@w{/* blah */}}, not an empty string.
-For end-of-line indicators, any of \n, \r\n, \n\r and \r are recognised,
-and treated as ending a single line. As a result, if you mix these in a
-single file you might get incorrect line numbering, because the
-preprocessor would interpret the two-character versions as ending just
-one line. Previous implementations would only handle UNIX-style \n
-correctly, so DOS-style \r\n would need to be passed through a filter
-first.
+Line comments are not in the 1989 edition of the C standard, but they
+are recognized by GCC as an extension. In C++ and in the 1999 edition
+of the C standard, they are an official part of the language.
+@end enumerate
-The first three transformations are done @emph{before} all other parsing
-and before preprocessing directives are recognized. Thus, for example,
-you can split a line mechanically with backslash-newline anywhere
-(except within trigraphs since they are replaced first; see below).
+Since these transformations happen before all other processing, you can
+split a line mechanically with backslash-newline anywhere. You can
+comment out the end of a line. You can continue a line comment onto the
+next line with backslash-newline. You can even split @samp{/*},
+@samp{*/}, and @samp{//} onto multiple lines with backslash-newline.
+For example:
@example
-/*
+@group
+/\
+*
*/ # /*
*/ defi\
ne FO\
O 10\
20
+@end group
@end example
@noindent
-is equivalent into @samp{#define FOO 1020}.
+is equivalent to @samp{@w{#define FOO 1020}}. All these tricks are
+extremely confusing and should not be used in code intended to be
+readable.
There is no way to prevent a backslash at the end of a line from being
-interpreted as a backslash-newline. For example,
+interpreted as a backslash-newline.
@example
"foo\\
bar"
@end example
+@noindent
is equivalent to @code{"foo\bar"}, not to @code{"foo\\bar"}. To avoid
having to worry about this, do not use the deprecated GNU extension
which permits multi-line strings. Instead, use string literal
"bar"
@end example
+@noindent
Your program will be more portable this way, too.
-There are a few things to note about the above four transformations.
+@node Tokenization
+@section Tokenization
+
+@cindex tokens
+@cindex preprocessing tokens
+After the textual transformations are finished, the input file is
+converted into a sequence of @dfn{preprocessing tokens}. These mostly
+correspond to the syntactic tokens used by the C compiler, but there are
+a few differences. White space separates tokens; it is not itself a
+token of any kind. Tokens do not have to be separated by white space,
+but it is often necessary to avoid ambiguities.
+
+When faced with a sequence of characters that has more than one possible
+tokenization, the preprocessor is greedy. It always makes each token,
+starting from the left, as big as possible before moving on to the next
+token. For instance, @samp{a+++++b} is interpreted as
+@samp{@w{a ++ ++ + b}}, not as @samp{@w{a ++ + ++ b}}, even though the
+latter tokenization could be part of a valid C program and the former
+could not.
+
+Once the input file is broken into tokens, the token boundaries never
+change, except when the @samp{##} preprocessing operator is used to glue
+tokens together. @xref{Concatenation}. For example,
-@itemize @bullet
-@item
-Comments and predefined macro names (or any macro names, for that
-matter) are not recognized inside the argument of an @samp{#include}
-directive, when it is delimited with quotes or with @samp{<} and
-@samp{>}.
+@example
+@group
+#define foo() bar
+foo()baz
+ @expansion{} bar baz
+@emph{not}
+ @expansion{} barbaz
+@end group
+@end example
-@item
-Comments and predefined macro names are never recognized within a
-character or string constant.
+The compiler does not re-tokenize the preprocessor's output. Each
+preprocessing token becomes one compiler token.
+
+@cindex identifiers
+Preprocessing tokens fall into five broad classes: identifiers,
+preprocessing numbers, string literals, punctuators, and other. An
+@dfn{identifier} is the same as an identifier in C: any sequence of
+letters, digits, or underscores, which begins with a letter or
+underscore. Keywords of C have no significance to the preprocessor;
+they are ordinary identifiers. You can define a macro whose name is a
+keyword, for instance. The only identifier which can be considered a
+preprocessing keyword is @samp{defined}. @xref{Defined}.
+
+This is mostly true of other languages which use the C preprocessor.
+However, a few of the keywords of C++ are significant even in the
+preprocessor. @xref{C++ Named Operators}.
+
+In the 1999 C standard, identifiers may contain letters which are not
+part of the ``basic source character set,'' at the implementation's
+discretion (such as accented Latin letters, Greek letters, or Chinese
+ideograms). This may be done with an extended character set, or the
+@samp{\u} and @samp{\U} escape sequences. GNU C does not presently
+implement either feature in the preprocessor or the compiler.
+
+@cindex numbers
+@cindex preprocessing numbers
+A @dfn{preprocessing number} has a rather bizarre definition. The
+category includes all the normal integer and floating point constants
+one expects of C, but also a number of other things one might not
+initially recognize as a number. Formally, preprocessing numbers begin
+with an optional period, a required decimal digit, and then continue
+with any sequence of letters, digits, underscores, periods, and
+exponents. Exponents are the two-character sequences @samp{e+},
+@samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, @samp{p-}, @samp{P+}, and
+@samp{P-}. (The exponents that begin with @samp{p} or @samp{P} are new
+to C99. They are used for hexadecimal floating-point constants.)
+
+The purpose of this unusual definition is to isolate the preprocessor
+from the full complexity of numeric constants. It does not have to
+distinguish between lexically valid and invalid floating-point numbers,
+which is complicated. The definition also permits you to split an
+identifier at any position and get exactly two tokens, which can then be
+glued back together with the @samp{##} operator.
+
+It's possible for preprocessing numbers to cause programs to be
+misinterpreted. For example, @samp{0xE+12} is a preprocessing number
+which does not translate to any valid numeric constant, therefore a
+syntax error. It does not mean @samp{@w{0xE + 12}}, which is what you
+might have intended.
+
+@cindex string literals
+@cindex string constants
+@cindex character constants
+@cindex header file names
+@c the @: prevents makeinfo from turning '' into ".
+@dfn{String literals} are string constants, character constants, and
+header file names (the argument of @samp{#include}).@footnote{The C
+standard uses the term @dfn{string literal} to refer only to what we are
+calling @dfn{string constants}.} String constants and character
+constants are straightforward: @t{"..."} or @t{'...'}. In either case
+the closing quote may be escaped with a backslash: @t{'\'@:'} is the
+character constant for @samp{'}. There is no limit on the length of a
+character constant, but the value of a character constant that contains
+more than one character is implementation-defined. @xref{Implementation
+Details}.
+
+Header file names either look like string constants, @t{"..."}, or are
+written with angle brackets instead, @t{<...>}. In either case,
+backslash is an ordinary character. There is no way to escape the
+closing quote or angle bracket. The preprocessor looks for the header
+file in different places depending on which form you use. @xref{Include
+Operation}.
+
+In standard C, no string literal may extend past the end of a line. GNU
+CPP accepts multi-line string constants, but not character constants or
+header file names. This extension is deprecated and will be removed in
+GCC 3.1. You may use continued lines instead, or string constant
+concatenation. @xref{Differences from previous versions}.
+
+@cindex punctuators
+@dfn{Punctuators} are all the usual bits of punctuation which are
+meaningful to C and C++. All but three of the punctuation characters in
+ASCII are C punctuators. The exceptions are @samp{@@}, @samp{$}, and
+@samp{`}. In addition, all the two- and three-character operators are
+punctuators. There are also six @dfn{digraphs}, which are merely
+alternate ways to spell other punctuators. This is a second attempt to
+work around missing punctuation in obsolete systems. It has no negative
+side effects, unlike trigraphs, but does not cover as much ground. The
+digraphs and their corresponding normal punctuators are:
-@item
-ISO ``trigraphs'' are converted before backslash-newlines are deleted.
-If you write what looks like a trigraph with a backslash-newline inside,
-the backslash-newline is deleted as usual, but it is too late to
-recognize the trigraph.
+@example
+Digraph: <% %> <: :> %: %:%:
+Punctuator: @{ @} [ ] # ##
+@end example
-This is relevant only if you use the @samp{-trigraphs} option to enable
-trigraph processing. @xref{Invocation}.
-@end itemize
+@cindex other tokens
+Any other single character is considered ``other.'' It is passed on to
+the preprocessor's output unmolested. The C compiler will almost
+certainly reject source code containing ``other'' tokens. In ASCII, the
+only other characters are @samp{@@}, @samp{$}, @samp{`}, and control
+characters other than NUL (all bits zero). All characters with the high
+bit set (numeric range 0x7F--0xFF) are also ``other'' in the present
+implementation. This will change when proper support for international
+character sets is added to GCC.
+
+NUL is a special case because of the high probability that its
+appearance is accidental, and because it may be invisible to the user
+(many terminals do not display NUL at all). Within comments, NULs are
+silently ignored, just as any other character would be. In running
+text, NUL is considered white space. For example, these two directives
+have the same meaning.
+
+@example
+#define X^@@1
+#define X 1
+@end example
+
+@noindent
+(where @samp{^@@} is ASCII NUL). Within string or character constants,
+NULs are preserved. In the latter two cases the preprocessor emits a
+warning message.
-The preprocessor handles null characters embedded in the input file
-depending upon the context in which the null appears. Note that here we
-are referring not to the two-character escape sequence "\0", but to the
-single character ASCII NUL.
+@node The preprocessing language
+@section The preprocessing language
+@cindex directives
+@cindex preprocessing directives
+@cindex directive line
+@cindex directive name
-There are three different contexts in which a null character may
-appear:
+After tokenization, the stream of tokens may simply be passed straight
+to the compiler's parser. However, if it contains any operations in the
+@dfn{preprocessing language}, it will be transformed first. This stage
+corresponds roughly to the standard's ``translation phase 4'' and is
+what most people think of as the preprocessor's job.
+
+The preprocessing language consists of @dfn{directives} to be executed
+and @dfn{macros} to be expanded. Its primary capabilities are:
@itemize @bullet
@item
-Within comments. Here, null characters are silently ignored.
+Inclusion of header files. These are files of declarations that can be
+substituted into your program.
@item
-Within a string or character constant. Here the preprocessor emits a
-warning, but preserves the null character and passes it through to the
-output file or compiler front-end.
+Macro expansion. You can define @dfn{macros}, which are abbreviations
+for arbitrary fragments of C code. The preprocessor will replace the
+macros with their definitions throughout the program. Some macros are
+automatically defined for you.
@item
-In any other context, the preprocessor issues a warning, and discards
-the null character. The preprocessor treats it like whitespace,
-combining it with any surrounding whitespace to become a single
-whitespace block. Representing the null character by "^@@", this means
-that code like
-
-@example
-#define X^@@1
-@end example
+Conditional compilation. You can include or exclude parts of the
+program according to various conditions.
-is equivalent to
-
-@example
-#define X 1
-@end example
+@item
+Line control. If you use a program to combine or rearrange source files
+into an intermediate file which is then compiled, you can use line
+control to inform the compiler where each source line originally came
+from.
-and X is defined with replacement text "1".
+@item
+Diagnostics. You can detect problems at compile time and issue errors
+or warnings.
@end itemize
-@node Directives, Header Files, Global Actions, Top
-@section Preprocessing Directives
-
-@cindex preprocessing directives
-@cindex directives
-Most preprocessor features are active only if you use preprocessing
-directives to request their use.
+There are a few more, less useful features.
-Preprocessing directives are lines in your program that start with
-@samp{#}. Whitespace is allowed before and after the @samp{#}. The
-@samp{#} is followed by an identifier that is the @dfn{directive name}.
-For example, @samp{#define} is the directive that defines a macro.
+Except for expansion of predefined macros, all these operations are
+triggered with @dfn{preprocessing directives}. Preprocessing directives
+are lines in your program that start with @samp{#}. Whitespace is
+allowed before and after the @samp{#}. The @samp{#} is followed by an
+identifier, the @dfn{directive name}. It specifies the operation to
+perform. Directives are commonly referred to as @samp{#@var{name}}
+where @var{name} is the directive name. For example, @samp{#define} is
+the directive that defines a macro.
-Since the @samp{#} must be the first token on the line, it cannot come
-from a macro expansion if you wish it to begin a directive. Also, the
-directive name is not macro expanded. Thus, if @samp{foo} is defined as
-a macro expanding to @samp{define}, that does not make @samp{#foo} a
-valid preprocessing directive.
+The @samp{#} which begins a directive cannot come from a macro
+expansion. Also, the directive name is not macro expanded. Thus, if
+@samp{foo} is defined as a macro expanding to @samp{define}, that does
+not make @samp{#foo} a valid preprocessing directive.
The set of valid directive names is fixed. Programs cannot define new
preprocessing directives.
-Some directive names require arguments; these make up the rest of the
+Some directives require arguments; these make up the rest of the
directive line and must be separated from the directive name by
whitespace. For example, @samp{#define} must be followed by a macro
-name and the intended expansion of the macro. @xref{Object-like
-Macros}.
+name and the intended expansion of the macro.
-A preprocessing directive cannot cover more than one line. It may be
-logically extended with backslash-newline, but that has no effect on its
-meaning. Comments containing newlines can also divide the directive
-into multiple lines, but a comment is replaced by a single space before
-the directive is interpreted.
+A preprocessing directive cannot cover more than one line. The line
+may, however, be continued with backslash-newline, or by a block comment
+which extends past the end of the line. In either case, when the
+directive is processed, the continuations have already been merged with
+the first line to make one long line.
-@node Header Files, Macros, Directives, Top
-@section Header Files
+@node Header Files
+@chapter Header Files
@cindex header file
A header file is a file containing C declarations and macro definitions
(@pxref{Macros}) to be shared between several source files. You request
-the use of a header file in your program with the C preprocessing
-directive @samp{#include}.
-
-@menu
-* Header Uses:: What header files are used for.
-* Include Syntax:: How to write @samp{#include} directives.
-* Include Operation:: What @samp{#include} does.
-* Once-Only:: Preventing multiple inclusion of one header file.
-* Inheritance:: Including one header file in another header file.
-* System Headers:: Special treatment for some header files.
-@end menu
-
-@node Header Uses, Include Syntax, Header Files, Header Files
-@subsection Uses of Header Files
+the use of a header file in your program by @dfn{including} it, with the
+C preprocessing directive @samp{#include}.
-Header files serve two kinds of purposes.
+Header files serve two purposes.
@itemize @bullet
@item
file for them.
@end itemize
-Including a header file produces the same results in C compilation as
-copying the header file into each source file that needs it. Such
-copying would be time-consuming and error-prone. With a header file,
-the related declarations appear in only one place. If they need to be
-changed, they can be changed in one place, and programs that include the
-header file will automatically use the new version when next recompiled.
-The header file eliminates the labor of finding and changing all the
-copies as well as the risk that a failure to find one copy will result
-in inconsistencies within a program.
+Including a header file produces the same results as copying the header
+file into each source file that needs it. Such copying would be
+time-consuming and error-prone. With a header file, the related
+declarations appear in only one place. If they need to be changed, they
+can be changed in one place, and programs that include the header file
+will automatically use the new version when next recompiled. The header
+file eliminates the labor of finding and changing all the copies as well
+as the risk that a failure to find one copy will result in
+inconsistencies within a program.
-The usual convention is to give header files names that end with
-@file{.h}. Avoid unusual characters in header file names, as they
-reduce portability.
+In C, the usual convention is to give header files names that end with
+@file{.h}. It is most portable to use only letters, digits, dashes, and
+underscores in header file names, and at most one dot.
+
+@menu
+* Include Syntax::
+* Include Operation::
+* Search Path::
+* Once-Only Headers::
+* Computed Includes::
+* Wrapper Headers::
+* System Headers::
+@end menu
-@node Include Syntax, Include Operation, Header Uses, Header Files
-@subsection The @samp{#include} Directive
+@node Include Syntax
+@section Include Syntax
@findex #include
Both user and system header files are included using the preprocessing
-directive @samp{#include}. It has three variants:
+directive @samp{#include}. It has two variants:
@table @code
@item #include <@var{file}>
This variant is used for system header files. It searches for a file
-named @var{file} in a list of directories specified by you, then in a
-standard list of system directories. You specify directories to search
-for header files with the command option @samp{-I} (@pxref{Invocation}).
-The option @samp{-nostdinc} inhibits searching the standard system
-directories; in this case only the directories you specify are searched.
-
-The first @samp{>} character terminates the file name. The file name
-may contain a @samp{<} character.
+named @var{file} in a standard list of system directories. You can prepend
+directories to this list with the @option{-I} option (@pxref{Invocation}).
@item #include "@var{file}"
This variant is used for header files of your own program. It searches
-for a file named @var{file} first in the current directory, then in the
-same directories used for system header files. The current directory is
-the directory of the current input file. It is tried first because it
-is presumed to be the location of the files that the current input file
-refers to. (If the @samp{-I-} option is used, the special treatment of
-the current directory is inhibited. @xref{Invocation}.)
-
-The first @samp{"} character terminates the file name.
-
-In both these variants, the argument behaves like a string constant in
-that comments are not recognized, and macro names are not expanded.
-Thus, in @samp{#include <x/*y>} the @samp{/*} does not start a comment
-and the directive specifies inclusion of a system header file named
-@file{x/*y}.
-
-However, in either variant, if backslashes occur within @var{file}, they
-are considered ordinary text characters, not escape characters. None of
-the character escape sequences appropriate to string constants in C are
-processed. Thus, @samp{#include "x\n\\y"} specifies a filename
-containing three backslashes.
-
-@item #include @var{anything else}
-@cindex computed @samp{#include}
-This variant is called a @dfn{computed #include}. Any @samp{#include}
-directive whose argument does not fit the above two forms is a computed
-include. The text @var{anything else} is checked for macro calls, which
-are expanded (@pxref{Macros}). When this is done, the result must match
-one of the above two variants --- in particular, the expansion must form
-a string literal token, or a sequence of tokens surrounded by angle
-braces. @xref{Implementation}.
-
-This feature allows you to define a macro which controls the file name
-to be used at a later point in the program. One application of this is
-to allow a site-specific configuration file for your program to specify
-the names of the system include files to be used. This can help in
-porting the program to various operating systems in which the necessary
-system header files are found in different places.
+for a file named @var{file} first in the directory containing the
+current file, then in the same directories used for @code{<@var{file}>}.
@end table
-@node Include Operation, Once-Only, Include Syntax, Header Files
-@subsection How @samp{#include} Works
+The argument of @samp{#include}, whether delimited with quote marks or
+angle brackets, behaves like a string constant in that comments are not
+recognized, and macro names are not expanded. Thus, @samp{@w{#include
+<x/*y>}} specifies inclusion of a system header file named @file{x/*y}.
+
+However, if backslashes occur within @var{file}, they are considered
+ordinary text characters, not escape characters. None of the character
+escape sequences appropriate to string constants in C are processed.
+Thus, @samp{@w{#include "x\n\\y"}} specifies a filename containing three
+backslashes. (Some systems interpret @samp{\} as a pathname separator.
+All of these also interpret @samp{/} the same way. It is most portable
+to use only @samp{/}.)
+
+It is an error if there is anything (other than comments) on the line
+after the file name.
+
+@node Include Operation
+@section Include Operation
The @samp{#include} directive works by directing the C preprocessor to
scan the specified file as input before continuing with the rest of the
current file. The output from the preprocessor contains the output
already generated, followed by the output resulting from the included
file, followed by the output that comes from the text after the
-@samp{#include} directive. For example, given a header file
+@samp{#include} directive. For example, if you have a header file
@file{header.h} as follows,
@example
-char *test ();
+char *test (void);
@end example
@noindent
int x;
#include "header.h"
-main ()
+int
+main (void)
@{
- printf (test ());
+ puts (test ());
@}
@end example
@noindent
-the output generated by the C preprocessor for @file{program.c} as input
-would be
+the compiler will see the same token stream as it would if
+@file{program.c} read
@example
int x;
-char *test ();
+char *test (void);
-main ()
+int
+main (void)
@{
- printf (test ());
+ puts (test ());
@}
@end example
comment, string constant or character constant in an included file is
considered to end (with an error message) at the end of the file.
-It is possible for a header file to begin or end a syntactic unit such
-as a function definition, but that would be very confusing, so don't do
-it.
+To avoid confusion, it is best if header files contain only complete
+syntactic units --- function declarations or definitions, type
+declarations, etc.
The line following the @samp{#include} directive is always treated as a
separate line by the C preprocessor, even if the included file lacks a
final newline.
-@node Once-Only, Inheritance, Include Operation, Header Files
-@subsection Once-Only Include Files
+@node Search Path
+@section Search Path
+
+GCC looks in several different places for headers. On a normal Unix
+system, if you do not instruct it otherwise, it will look for headers
+requested with @samp{@w{#include <@var{file}>}} in:
+
+@example
+/usr/local/include
+/usr/lib/gcc-lib/@var{target}/@var{version}/include
+/usr/@var{target}/include
+/usr/include
+@end example
+
+For C++ programs, it will also look in @samp{/usr/include/g++-v3},
+first. In the above, @var{target} is the canonical name of the system
+GCC was configured to compile code for; often but not always the same as
+the canonical name of the system it runs on. @var{version} is the
+version of GCC in use.
+
+You can add to this list with the @option{-I@var{dir}} command line
+option. All the directories named by @option{-I} are searched, in
+left-to-right order, @emph{before} the default directories. You can
+also prevent GCC from searching any of the default directories with the
+@option{-nostdinc} option. This is useful when you are compiling an
+operating system kernel or some other program that does not use the
+standard C library facilities, or the standard C library itself.
+
+GCC looks for headers requested with @samp{@w{#include "@var{file}"}}
+first in the directory containing the current file, then in the same
+places it would have looked for a header requested with angle brackets.
+For example, if @file{/usr/include/sys/stat.h} contains
+@samp{@w{#include "types.h"}}, GCC looks for @file{types.h} first in
+@file{/usr/include/sys}, then in its usual search path.
+
+@samp{#line} (@pxref{Line Control}) does not change GCC's idea of the
+directory containing the current file.
+
+You may put @option{-I-} at any point in your list of @option{-I} options.
+This has two effects. First, directories appearing before the
+@option{-I-} in the list are searched only for headers requested with
+quote marks. Directories after @option{-I-} are searched for all
+headers. Second, the directory containing the current file is not
+searched for anything, unless it happens to be one of the directories
+named by an @option{-I} switch.
+
+@option{-I. -I-} is not the same as no @option{-I} options at all, and does
+not cause the same behavior for @samp{<>} includes that @samp{""}
+includes get with no special options. @option{-I.} searches the
+compiler's current working directory for header files. That may or may
+not be the same as the directory containing the current file.
+
+If you need to look for headers in a directory named @file{-}, write
+@option{-I./-}.
+
+There are several more ways to adjust the header search path. They are
+less generally useful. @xref{Invocation}.
+
+@node Once-Only Headers
+@section Once-Only Headers
@cindex repeated inclusion
@cindex including just once
+@cindex wrapper @code{#ifndef}
-Very often, one header file includes another. It can easily result that
-a certain header file is included more than once. This may lead to
-errors, if the header file defines structure types or typedefs, and is
-certainly wasteful. Therefore, we often wish to prevent multiple
-inclusion of a header file.
+If a header file happens to be included twice, the compiler will process
+its contents twice. This is very likely to cause an error, e.g. when the
+compiler sees the same structure definition twice. Even if it does not,
+it will certainly waste time.
-The standard way to do this is to enclose the entire real contents of the
-file in a conditional, like this:
+The standard way to prevent this is to enclose the entire real contents
+of the file in a conditional, like this:
@example
+@group
+/* File foo. */
#ifndef FILE_FOO_SEEN
#define FILE_FOO_SEEN
@var{the entire file}
#endif /* FILE_FOO_SEEN */
+@end group
@end example
-The macro @code{FILE_FOO_SEEN} indicates that the file has been included
-once already. In a user header file, the macro name should not begin
-with @samp{_}. In a system header file, this name should begin with
+This construct is commonly known as a @dfn{wrapper #ifndef}.
+When the header is included again, the conditional will be false,
+because @code{FILE_FOO_SEEN} is defined. The preprocessor will skip
+over the entire contents of the file, and the compiler will not see it
+twice.
+
+GNU CPP optimizes even further. It remembers when a header file has a
+wrapper @samp{#ifndef}. If a subsequent @samp{#include} specifies that
+header, and the macro in the @samp{#ifndef} is still defined, it does
+not bother to rescan the file at all.
+
+You can put comments outside the wrapper. They will not interfere with
+this optimization.
+
+@cindex controlling macro
+@cindex guard macro
+The macro @code{FILE_FOO_SEEN} is called the @dfn{controlling macro} or
+@dfn{guard macro}. In a user header file, the macro name should not
+begin with @samp{_}. In a system header file, it should begin with
@samp{__} to avoid conflicts with user programs. In any kind of header
file, the macro name should contain the name of the file and some
additional text, to avoid conflicts with other header files.
-The GNU C preprocessor is programmed to notice when a header file uses
-this particular construct and handle it efficiently. If a header file
-is contained entirely in a @samp{#ifndef} conditional, modulo whitespace
-and comments, then it remembers that fact. If a subsequent
-@samp{#include} specifies the same file, and the macro in the
-@samp{#ifndef} is already defined, then the directive is skipped without
-processing the specified file at all.
+@node Computed Includes
+@section Computed Includes
+@cindex computed includes
+@cindex macros in include
-@findex #import
-In the Objective C language, there is a variant of @samp{#include}
-called @samp{#import} which includes a file, but does so at most once.
-If you use @samp{#import} @emph{instead of} @samp{#include}, then you
-don't need the conditionals inside the header file to prevent multiple
-execution of the contents.
-
-@samp{#import} is obsolete because it is not a well designed feature.
-It requires the users of a header file --- the applications programmers
---- to know that a certain header file should only be included once. It
-is much better for the header file's implementor to write the file so
-that users don't need to know this. Using @samp{#ifndef} accomplishes
-this goal.
+Sometimes it is necessary to select one of several different header
+files to be included into your program. They might specify
+configuration parameters to be used on different sorts of operating
+systems, for instance. You could do this with a series of conditionals,
-@node Inheritance, System Headers, Once-Only, Header Files
-@subsection Inheritance and Header Files
-@cindex inheritance
-@cindex overriding a header file
+@example
+#if SYSTEM_1
+# include "system_1.h"
+#elif SYSTEM_2
+# include "system_2.h"
+#elif SYSTEM_3
+@dots{}
+#endif
+@end example
+
+That rapidly becomes tedious. Instead, the preprocessor offers the
+ability to use a macro for the header name. This is called a
+@dfn{computed include}. Instead of writing a header name as the direct
+argument of @samp{#include}, you simply put a macro name there instead:
+
+@example
+#define SYSTEM_H "system_1.h"
+@dots{}
+#include SYSTEM_H
+@end example
+
+@samp{SYSTEM_H} will be expanded, and the preprocessor will look for
+@file{system_1.h} as if the @samp{#include} had been written that way
+originally. @samp{SYSTEM_H} could be defined by your Makefile with a
+@option{-D} option.
+
+You must be careful when you define the macro. @samp{#define} saves
+tokens, not text. The preprocessor has no way of knowing that the macro
+will be used as the argument of @samp{#include}, so it generates
+ordinary tokens, not a header name. This is unlikely to cause problems
+if you use double-quote includes, which are close enough to string
+constants. If you use angle brackets, however, you may have trouble.
-@dfn{Inheritance} is what happens when one object or file derives some
-of its contents by virtual copying from another object or file. In
-the case of C header files, inheritance means that one header file
-includes another header file and then replaces or adds something.
-
-If the inheriting header file and the base header file have different
-names, then inheritance is straightforward: simply write @samp{#include
-"@var{base}"} in the inheriting file.
-
-Sometimes it is necessary to give the inheriting file the same name as
-the base file. This is less straightforward.
-
-For example, suppose an application program uses the system header
-@file{sys/signal.h}, but the version of @file{/usr/include/sys/signal.h}
-on a particular system doesn't do what the application program expects.
-It might be convenient to define a ``local'' version, perhaps under the
-name @file{/usr/local/include/sys/signal.h}, to override or add to the
-one supplied by the system.
-
-You can do this by compiling with the option @samp{-I.}, and writing a
-file @file{sys/signal.h} that does what the application program expects.
-Making this file include the standard @file{sys/signal.h} is not so easy
---- writing @samp{#include <sys/signal.h>} in that file doesn't work,
-because it includes your own version of the file, not the standard
-system version. Used in that file itself, this leads to an infinite
-recursion and a fatal error in compilation.
-
-@samp{#include </usr/include/sys/signal.h>} would find the proper file,
-but that is not clean, since it makes an assumption about where the
-system header file is found. This is bad for maintenance, since it
-means that any change in where the system's header files are kept
-requires a change somewhere else.
+The syntax of a computed include is actually a bit more general than the
+above. If the first non-whitespace character after @samp{#include} is
+not @samp{"} or @samp{<}, then the entire line is macro-expanded
+like running text would be.
+If the line expands to a single string constant, the contents of that
+string constant are the file to be included. CPP does not reexamine the
+string for embedded quotes, but neither does it process backslash
+escapes in the string. Therefore
+
+@example
+#define HEADER "a\"b"
+#include HEADER
+@end example
+
+looks for a file named @file{a\"b}. CPP searches for the file according
+to the rules for double-quoted includes.
+
+If the line expands to a token stream beginning with a @samp{<} token
+and including a @samp{>} token, then the tokens between the @samp{<} and
+the first @samp{>} are combined to form the filename to be included.
+Any whitespace between tokens is reduced to a single space; then any
+space after the initial @samp{<} is retained, but a trailing space
+before the closing @samp{>} is ignored. CPP searches for the file
+according to the rules for angle-bracket includes.
+
+In either case, if there are any tokens on the line after the file name,
+an error occurs and the directive is not processed. It is also an error
+if the result of expansion does not match either of the two expected
+forms.
+
+These rules are implementation-defined behavior according to the C
+standard. To minimize the risk of different compilers interpreting your
+computed includes differently, we recommend you use only a single
+object-like macro which expands to a string constant. This will also
+minimize confusion of people reading your program.
+
+@node Wrapper Headers
+@section Wrapper Headers
+@cindex wrapper headers
+@cindex overriding a header file
@findex #include_next
-The clean way to solve this problem is to use
-@samp{#include_next}, which means, ``Include the @emph{next} file with
-this name.'' This directive works like @samp{#include} except in
-searching for the specified file: it starts searching the list of header
-file directories @emph{after} the directory in which the current file
-was found.
-
-Suppose you specify @samp{-I /usr/local/include}, and the list of
+
+Sometimes it is necessary to adjust the contents of a system-provided
+header file without editing it directly. GCC's @samp{fixincludes}
+operation does this, for example. One way to do that would be to create
+a new header file with the same name and insert it in the search path
+before the original header. That works fine as long as you're willing
+to replace the old header entirely. But what if you want to refer to
+the old header from the new one?
+
+You cannot simply include the old header with @samp{#include}. That
+will start from the beginning, and find your new header again. If your
+header is not protected from multiple inclusion (@pxref{Once-Only
+Headers}), it will recurse infinitely and cause a fatal error.
+
+You could include the old header with an absolute pathname:
+@example
+#include "/usr/include/old-header.h"
+@end example
+@noindent
+This works, but is not clean; should the system headers ever move, you
+would have to edit the new headers to match.
+
+There is no way to solve this problem within the C standard, but you can
+use the GNU extension @samp{#include_next}. It means, ``Include the
+@emph{next} file with this name.'' This directive works like
+@samp{#include} except in searching for the specified file: it starts
+searching the list of header file directories @emph{after} the directory
+in which the current file was found.
+
+Suppose you specify @option{-I /usr/local/include}, and the list of
directories to search also includes @file{/usr/include}; and suppose
-both directories contain @file{sys/signal.h}. Ordinary @samp{#include
-<sys/signal.h>} finds the file under @file{/usr/local/include}. If that
-file contains @samp{#include_next <sys/signal.h>}, it starts searching
+both directories contain @file{signal.h}. Ordinary @samp{#include
+<signal.h>} finds the file under @file{/usr/local/include}. If that
+file contains @samp{#include_next <signal.h>}, it starts searching
after that directory, and finds the file in @file{/usr/include}.
-@samp{#include_next} is a GCC extension and should not be used in
-programs intended to be portable to other compilers.
+@samp{#include_next} does not distinguish between @samp{<@var{file}>}
+and @samp{"@var{file}"} inclusion, nor does it check that the file you
+specify has the same name as the current file. It simply looks for the
+file named, starting with the directory in the search path after the one
+where the current file was found.
+
+The use of @samp{#include_next} can lead to great confusion. We
+recommend it be used only when there is no other alternative. In
+particular, it should not be used in the headers belonging to a
+specific program, only to make global corrections along the lines
+of @samp{fixincludes}.
-@node System Headers,, Inheritance, Header Files
-@subsection System Headers
+@node System Headers
+@section System Headers
@cindex system header files
The header files declaring interfaces to the operating system and
-runtime libraries often cannot be written in strictly conforming C.
+runtime libraries often cannot be written in strictly conforming C@.
Therefore, GNU C gives code found in @dfn{system headers} special
-treatment. Certain categories of warnings are suppressed, notably those
-enabled by @samp{-pedantic}.
+treatment. All warnings, other than those generated by @samp{#warning}
+(@pxref{Diagnostics}), are suppressed while GCC is processing a system
+header. Macros defined in a system header are immune to a few warnings
+wherever they are expanded. This immunity is granted on an ad-hoc
+basis, when we find that a warning generates lots of false positives
+because of code in macros defined in system headers.
Normally, only the headers found in specific directories are considered
-system headers. The set of these directories is determined when GCC is
-compiled. There are, however, two ways to add to the set.
-
-@findex -isystem
-The @samp{-isystem} command line option adds its argument to the list of
-directories to search for headers, just like @samp{-I}. In addition,
-any headers found in that directory will be considered system headers.
-Note that unlike @samp{-I}, you must put a space between @samp{-isystem}
-and its argument.
-
-All directories named by @samp{-isystem} are searched @strong{after} all
-directories named by @samp{-I}, no matter what their order was on the
-command line. If the same directory is named by both @samp{-I} and
-@samp{-isystem}, @samp{-I} wins; it is as if the @samp{-isystem} option
+system headers. These directories are determined when GCC is compiled.
+There are, however, two ways to make normal headers into system headers.
+
+The @option{-isystem} command line option adds its argument to the list of
+directories to search for headers, just like @option{-I}. Any headers
+found in that directory will be considered system headers. Note that
+unlike @option{-I}, you must put a space between @option{-isystem} and its
+argument.
+
+All directories named by @option{-isystem} are searched @emph{after} all
+directories named by @option{-I}, no matter what their order was on the
+command line. If the same directory is named by both @option{-I} and
+@option{-isystem}, @option{-I} wins; it is as if the @option{-isystem} option
had never been specified at all.
@findex #pragma GCC system_header
-There is also a directive, @samp{#pragma GCC system_header}, which tells
-GCC to consider the rest of the current include file a system header, no
-matter where it was found. Code that comes before the @samp{#pragma} in
-the file will not be affected.
-
-@samp{#pragma GCC system_header} has no effect in the primary source file.
-
-@node Macros, Conditionals, Header Files, Top
-@section Macros
-
-A macro is a sort of abbreviation which you can define once and then
-use later. There are many complicated features associated with macros
-in the C preprocessor.
+There is also a directive, @samp{@w{#pragma GCC system_header}}, which
+tells GCC to consider the rest of the current include file a system
+header, no matter where it was found. Code that comes before the
+@samp{#pragma} in the file will not be affected. @samp{@w{#pragma GCC
+system_header}} has no effect in the primary source file.
+
+On very old systems, some of the pre-defined system header directories
+get even more special treatment. GNU C++ considers code in headers
+found in those directories to be surrounded by an @code{@w{extern "C"}}
+block. There is no way to request this behavior with a @samp{#pragma},
+or from the command line.
+
+@node Macros
+@chapter Macros
+
+A @dfn{macro} is a fragment of code which has been given a name.
+Whenever the name is used, it is replaced by the contents of the macro.
+There are two kinds of macros. They differ mostly in what they look
+like when they are used. @dfn{Object-like} macros resemble data objects
+when used, @dfn{function-like} macros resemble function calls.
+
+You may define any valid identifier as a macro, even if it is a C
+keyword. The preprocessor does not know anything about keywords. This
+can be useful if you wish to hide a keyword such as @samp{const} from an
+older compiler that does not understand it. However, the preprocessor
+operator @samp{defined} (@pxref{Defined}) can never be defined as a
+macro, and C++'s named operators (@pxref{C++ Named Operators}) cannot be
+macros when you are compiling C++.
@menu
-* Object-like Macros:: Macros that always expand the same way.
-* Function-like Macros:: Macros that accept arguments that are substituted
- into the macro expansion.
-* Macro Varargs:: Macros with variable number of arguments.
-* Predefined:: Predefined macros that are always available.
-* Stringification:: Macro arguments converted into string constants.
-* Concatenation:: Building tokens from parts taken from macro arguments.
-* Undefining:: Cancelling a macro's definition.
-* Redefining:: Changing a macro's definition.
-* Poisoning:: Ensuring a macro is never defined or used.
-* Macro Pitfalls:: Macros can confuse the unwary. Here we explain
- several common problems and strange features.
+* Object-like Macros::
+* Function-like Macros::
+* Macro Arguments::
+* Stringification::
+* Concatenation::
+* Variadic Macros::
+* Predefined Macros::
+* Undefining and Redefining Macros::
+* Macro Pitfalls::
@end menu
-@node Object-like Macros, Function-like Macros, Macros, Macros
-@subsection Object-like Macros
+@node Object-like Macros
+@section Object-like Macros
@cindex object-like macro
-@cindex manifest constant
+@cindex symbolic constants
+@cindex manifest constants
-An @dfn{object-like macro} is a kind of abbreviation. It is a name
-which stands for a fragment of code. Some people refer to these as
-@dfn{manifest constants}.
+An @dfn{object-like macro} is a simple identifier which will be replaced
+by a code fragment. It is called object-like because it looks like a
+data object in code that uses it. They are most commonly used to give
+symbolic names to numeric constants.
-Before you can use a macro, you must @dfn{define} it explicitly with the
-@samp{#define} directive. @samp{#define} is followed by the name of the
-macro and then the token sequence it should be an abbreviation for,
-which is variously referred to as the macro's @dfn{body},
-@dfn{expansion} or @dfn{replacement list}. For example,
+@findex #define
+You create macros with the @samp{#define} directive. @samp{#define} is
+followed by the name of the macro and then the token sequence it should
+be an abbreviation for, which is variously referred to as the macro's
+@dfn{body}, @dfn{expansion} or @dfn{replacement list}. For example,
@example
-#define BUFFER_SIZE 1020
+#define BUFFER_SIZE 1024
@end example
@noindent
defines a macro named @samp{BUFFER_SIZE} as an abbreviation for the
-token @samp{1020}. If somewhere after this @samp{#define} directive
+token @samp{1024}. If somewhere after this @samp{#define} directive
there comes a C statement of the form
@example
-foo = (char *) xmalloc (BUFFER_SIZE);
+foo = (char *) malloc (BUFFER_SIZE);
@end example
@noindent
then the C preprocessor will recognize and @dfn{expand} the macro
-@samp{BUFFER_SIZE}, resulting in
+@samp{BUFFER_SIZE}. The C compiler will see the same tokens as it would
+if you had written
@example
-foo = (char *) xmalloc (1020);
+foo = (char *) malloc (1024);
@end example
-The use of all upper case for macro names is a standard convention.
-Programs are easier to read when it is possible to tell at a glance
-which names are macros.
+By convention, macro names are written in upper case. Programs are
+easier to read when it is possible to tell at a glance which names are
+macros.
+
+The macro's body ends at the end of the @samp{#define} line. You may
+continue the definition onto multiple lines, if necessary, using
+backslash-newline. When the macro is expanded, however, it will all
+come out on one line. For example,
+
+@example
+#define NUMBERS 1, \
+ 2, \
+ 3
+int x[] = @{ NUMBERS @};
+ @expansion{} int x[] = @{ 1, 2, 3 @};
+@end example
-Normally, a macro definition can only span a single logical line, like
-all C preprocessing directives. Comments within a macro definition may
-contain newlines, which make no difference since each comment is
-replaced by a space regardless of its contents.
+@noindent
+The most common visible consequence of this is surprising line numbers
+in error messages.
-Apart from this, there is no restriction on what can go in a macro body
-provided it decomposes into valid preprocessing tokens. In particular,
-parentheses need not balance, and the body need not resemble valid C
-code. (If it does not, you may get error messages from the C
-compiler when you use the macro.)
+There is no restriction on what can go in a macro body provided it
+decomposes into valid preprocessing tokens. Parentheses need not
+balance, and the body need not resemble valid C code. (If it does not,
+you may get error messages from the C compiler when you use the macro.)
-The C preprocessor scans your program sequentially, so macro definitions
+The C preprocessor scans your program sequentially. Macro definitions
take effect at the place you write them. Therefore, the following input
to the C preprocessor
@end example
@noindent
-produces as output
+produces
@example
foo = X;
-
bar = 4;
@end example
When the preprocessor expands a macro name, the macro's expansion
-replaces the macro invocation, and the result is re-scanned for more
-macros to expand. For example, after
+replaces the macro invocation, then the expansion is examined for more
+macros to expand. For example,
+
+@example
+@group
+#define TABLESIZE BUFSIZE
+#define BUFSIZE 1024
+TABLESIZE
+ @expansion{} BUFSIZE
+ @expansion{} 1024
+@end group
+@end example
+
+@noindent
+@samp{TABLESIZE} is expanded first to produce @samp{BUFSIZE}, then that
+macro is expanded to produce the final result, @samp{1024}.
+
+Notice that @samp{BUFSIZE} was not defined when @samp{TABLESIZE} was
+defined. The @samp{#define} for @samp{TABLESIZE} uses exactly the
+expansion you specify --- in this case, @samp{BUFSIZE} --- and does not
+check to see whether it too contains macro names. Only when you
+@emph{use} @samp{TABLESIZE} is the result of its expansion scanned for
+more macro names.
+
+This makes a difference if you change the definition of @samp{BUFSIZE}
+at some point in the source file. @samp{TABLESIZE}, defined as shown,
+will always expand using the definition of @samp{BUFSIZE} that is
+currently in effect:
@example
#define BUFSIZE 1020
#define TABLESIZE BUFSIZE
+#undef BUFSIZE
+#define BUFSIZE 37
@end example
@noindent
-the name @samp{TABLESIZE} when used in the program would go through two
-stages of expansion, resulting ultimately in @samp{1020}.
-
-This is not the same as defining @samp{TABLESIZE} to be @samp{1020}.
-The @samp{#define} for @samp{TABLESIZE} uses exactly the expansion you
-specify --- in this case, @samp{BUFSIZE} --- and does not check to see
-whether it too contains macro names. Only when you @emph{use}
-@samp{TABLESIZE} is the result of its expansion scanned for more macro
-names. @xref{Cascaded Macros}.
-
-@node Function-like Macros, Macro Varargs, Object-like Macros, Macros
-@subsection Macros with Arguments
-@cindex macros with argument
-@cindex arguments in macro definitions
-@cindex function-like macro
+Now @samp{TABLESIZE} expands (in two stages) to @samp{37}.
-An object-like macro is always replaced by exactly the same tokens each
-time it is used. Macros can be made more flexible by taking
-@dfn{arguments}. Arguments are fragments of code that you supply each
-time the macro is used. These fragments are included in the expansion
-of the macro according to the directions in the macro definition. A
-macro that accepts arguments is called a @dfn{function-like macro}
-because the syntax for using it looks like a function call.
+If the expansion of a macro contains its own name, either directly or
+via intermediate macros, it is not expanded again when the expansion is
+examined for more macros. This prevents infinite recursion.
+@xref{Self-Referential Macros}, for the precise details.
-@findex #define
-To define a macro that uses arguments, you write a @samp{#define}
-directive with a list of @dfn{parameters} in parentheses after the name
-of the macro. The parameters must be valid C identifiers, separated by
-commas and optionally whitespace. The @samp{(} must follow the macro
-name immediately, with no space in between. If you leave a space, you
-instead define an object-like macro whose expansion begins with a
-@samp{(}, and often leads to confusing errors at compile time.
+@node Function-like Macros
+@section Function-like Macros
+@cindex function-like macros
-As an example, here is a macro that computes the minimum of two numeric
-values, as it is defined in many C programs:
+You can also define macros whose use looks like a function call. These
+are called @dfn{function-like macros}. To define a function-like macro,
+you use the same @samp{#define} directive, but you put a pair of
+parentheses immediately after the macro name. For example,
@example
-#define min(X, Y) ((X) < (Y) ? (X) : (Y))
+#define lang_init() c_init()
+lang_init()
+ @expansion{} c_init()
@end example
-@noindent
-(This is not the best way to define a ``minimum'' macro in GNU C@.
-@xref{Side Effects}, for more information.)
+A function-like macro is only expanded if its name appears with a pair
+of parentheses after it. If you write just the name, it is left alone.
+This can be useful when you have a function and a macro of the same
+name, and you wish to use the function sometimes.
+
+@example
+extern void foo(void);
+#define foo() /* optimized inline version */
+@dots{}
+ foo();
+ funcptr = foo;
+@end example
-To invoke a function-like macro, you write the name of the macro
-followed by a list of @dfn{arguments} in parentheses, separated by
-commas. The invocation of the macro need not be restricted to a single
-logical line - it can cross as many lines in the source file as you
-wish. The number of arguments you give must match the number of
-parameters in the macro definition; empty arguments are fine. Examples
-of use of the macro @samp{min} include @samp{min (1, 2)} and @samp{min
-(x + 28, *p)}.
+Here the call to @samp{foo()} will use the macro, but the function
+pointer will get the address of the real function. If the macro were to
+be expanded, it would cause a syntax error.
-The expansion text of the macro depends on the arguments you use. Each
-macro parameter is replaced throughout the macro expansion with the
-tokens of the corresponding argument. Leading and trailing argument
-whitespace is dropped, and all whitespace between the tokens of an
-argument is reduced to a single space. Using the same macro @samp{min}
-defined above, @samp{min (1, 2)} expands into
+If you put spaces between the macro name and the parentheses in the
+macro definition, that does not define a function-like macro, it defines
+an object-like macro whose expansion happens to begin with a pair of
+parentheses.
@example
-((1) < (2) ? (1) : (2))
+#define lang_init () c_init()
+lang_init()
+ @expansion{} () c_init()()
@end example
-@noindent
-where @samp{1} has been substituted for @samp{X} and @samp{2} for @samp{Y}.
+The first two pairs of parentheses in this expansion come from the
+macro. The third is the pair that was originally after the macro
+invocation. Since @samp{lang_init} is an object-like macro, it does not
+consume those parentheses.
+
+@node Macro Arguments
+@section Macro Arguments
+@cindex arguments
+@cindex macros with arguments
+@cindex arguments in macro definitions
+
+Function-like macros can take @dfn{arguments}, just like true functions.
+To define a macro that uses arguments, you insert @dfn{parameters}
+between the pair of parentheses in the macro definition that make the
+macro function-like. The parameters must be valid C identifiers,
+separated by commas and optionally whitespace.
+
+To invoke a macro that takes arguments, you write the name of the macro
+followed by a list of @dfn{actual arguments} in parentheses, separated
+by commas. The invocation of the macro need not be restricted to a
+single logical line - it can cross as many lines in the source file as
+you wish. The number of arguments you give must match the number of
+parameters in the macro definition. When the macro is expanded, each
+use of a parameter in its body is replaced by the tokens of the
+corresponding argument. (You need not use all of the parameters in the
+macro body.)
-Likewise, @samp{min (x + 28, *p)} expands into
+As an example, here is a macro that computes the minimum of two numeric
+values, as it is defined in many C programs, and some uses.
@example
-((x + 28) < (*p) ? (x + 28) : (*p))
+#define min(X, Y) ((X) < (Y) ? (X) : (Y))
+ x = min(a, b); @expansion{} x = ((a) < (b) ? (a) : (b));
+ y = min(1, 2); @expansion{} y = ((1) < (2) ? (1) : (2));
+ z = min(a + 28, *p); @expansion{} z = ((a + 28) < (*p) ? (a + 28) : (*p));
@end example
-Parentheses within each argument must balance; a comma within such
-parentheses does not end the argument. However, there is no requirement
-for square brackets or braces to balance, and they do not prevent a
-comma from separating arguments. Thus,
+@noindent
+(In this small example you can already see several of the dangers of
+macro arguments. @xref{Macro Pitfalls}, for detailed explanations.)
+
+Leading and trailing whitespace in each argument is dropped, and all
+whitespace between the tokens of an argument is reduced to a single
+space. Parentheses within each argument must balance; a comma within
+such parentheses does not end the argument. However, there is no
+requirement for square brackets or braces to balance, and they do not
+prevent a comma from separating arguments. Thus,
@example
macro (array[x = y, x + 1])
@noindent
passes two arguments to @code{macro}: @samp{array[x = y} and @samp{x +
1]}. If you want to supply @samp{array[x = y, x + 1]} as an argument,
-you must write it as @samp{array[(x = y, x + 1)]}, which is equivalent C
+you can write it as @samp{array[(x = y, x + 1)]}, which is equivalent C
code.
-After the arguments have been substituted into the macro body, the
-resulting expansion replaces the macro invocation, and re-scanned for
-more macro calls. Therefore even arguments can contain calls to other
-macros, either with or without arguments, and even to the same macro.
-For example, @samp{min (min (a, b), c)} expands into this text:
+All arguments to a macro are completely macro-expanded before they are
+substituted into the macro body. After substitution, the complete text
+is scanned again for macros to expand, including the arguments. This rule
+may seem strange, but it is carefully designed so you need not worry
+about whether any function call is actually a macro invocation. You can
+run into trouble if you try to be too clever, though. @xref{Argument
+Prescan}, for detailed discussion.
+
+For example, @samp{min (min (a, b), c)} is first expanded to
+
+@example
+ min (((a) < (b) ? (a) : (b)), (c))
+@end example
+
+@noindent
+and then to
@example
+@group
((((a) < (b) ? (a) : (b))) < (c)
? (((a) < (b) ? (a) : (b)))
: (c))
+@end group
@end example
@noindent
(Line breaks shown here for clarity would not actually be generated.)
@cindex empty macro arguments
-If a macro @code{foo} takes one argument, and you want to supply an
-empty argument, simply supply no preprocessing tokens. Since whitespace
-does not form a preprocessing token, it is optional. For example,
-@samp{foo ()}, @samp{foo ( )} and @samp{bar (, arg2)}.
-
-Previous GNU preprocessor implementations and documentation were
-incorrect on this point, insisting that a function-like macro that takes
-a single argument be passed a space if an empty argument was required.
-
-If you use a macro name followed by something other than a @samp{(}
-(after ignoring any whitespace that might follow), it does not form an
-invocation of the macro, and the preprocessor does not change what you
-have written. Therefore, it is possible for the same identifier to be a
-variable or function in your program as well as a macro, and you can
-choose in each instance whether to refer to the macro (if an actual
-argument list follows) or the variable or function (if an argument list
-does not follow). For example,
+You can leave macro arguments empty; this is not an error for the
+preprocessor (but many macros will then expand to invalid code).
+You cannot leave out arguments entirely; if a macro takes two arguments,
+there must be exactly one comma at the top level of its argument list.
+Here are some silly examples using @samp{min}:
@example
-#define foo(X) X
-foo bar foo(baz)
-@end example
+min(, b) @expansion{} (( ) < (b) ? ( ) : (b))
+min(a, ) @expansion{} ((a ) < ( ) ? (a ) : ( ))
+min(,) @expansion{} (( ) < ( ) ? ( ) : ( ))
+min((,),) @expansion{} (((,)) < ( ) ? ((,)) : ( ))
-expands to @samp{foo bar baz}. Such dual use of one name could be
-confusing and should be avoided except when the two meanings are
-effectively synonymous: that is, when the name is both a macro and a
-function and the two have similar effects. You can think of the name
-simply as a function; use of the name for purposes other than calling it
-(such as, to take the address) will refer to the function, while calls
-will expand the macro and generate better but equivalent code.
+min() @error{} macro "min" requires 2 arguments, but only 1 given
+min(,,) @error{} macro "min" passed 3 arguments, but takes just 2
+@end example
-For example, you can use a function named @samp{min} in the same source
-file that defines the macro. If you write @samp{&min} with no argument
-list, you refer to the function. If you write @samp{min (x, bb)}, with
-an argument list, the macro is expanded. If you write @samp{(min) (a,
-bb)}, where the name @samp{min} is not followed by an open-parenthesis,
-the macro is not expanded, so you wind up with a call to the function
-@samp{min}.
+Whitespace is not a preprocessing token, so if a macro @code{foo} takes
+one argument, @samp{@w{foo ()}} and @samp{@w{foo ( )}} both supply it an
+empty argument. Previous GNU preprocessor implementations and
+documentation were incorrect on this point, insisting that a
+function-like macro that takes a single argument be passed a space if an
+empty argument was required.
-In the definition of a macro with arguments, the list of argument names
-must follow the macro name immediately with no space in between. If
-there is a space after the macro name, the macro is defined as taking no
-arguments, and all the rest of the line is taken to be the expansion.
-The reason for this is that it is often useful to define a macro that
-takes no arguments and whose definition begins with an identifier in
-parentheses. This rule makes it possible for you to do either this:
+Macro parameters are not replaced by their corresponding actual
+arguments if they appear inside string literals.
@example
-#define FOO(x) - 1 / (x)
+#define foo(x) x, "x"
+foo(bar) @expansion{} bar, "x"
@end example
-@noindent
-(which defines @samp{FOO} to take an argument and expand into minus the
-reciprocal of that argument) or this:
+@node Stringification
+@section Stringification
+@cindex stringification
+@cindex @samp{#} operator
+
+Sometimes you may want to convert a macro argument into a string
+constant. Parameters are not replaced inside string constants, but you
+can use the @samp{#} preprocessing operator instead. When a macro
+parameter is used with a leading @samp{#}, the preprocessor replaces it
+with the literal text of the actual argument, converted to a string
+constant. Unlike normal parameter replacement, the argument is not
+macro-expanded first. This is called @dfn{stringification}.
+
+There is no way to combine an argument with surrounding text and
+stringify it all together. Instead, you can write a series of adjacent
+string constants and stringified arguments. The preprocessor will
+replace the stringified arguments with more string constants. The C
+compiler will then combine all the adjacent string constants into one
+long string.
+
+Here is an example of a macro definition that uses stringification:
@example
-#define BAR (x) - 1 / (x)
+@group
+#define WARN_IF(EXP) \
+do @{ if (EXP) \
+ fprintf (stderr, "Warning: " #EXP "\n"); @} \
+while (0)
+WARN_IF (x == 0);
+ @expansion{} do @{ if (x == 0)
+ fprintf (stderr, "Warning: " "x == 0" "\n"); @} while (0);
+@end group
@end example
@noindent
-(which defines @samp{BAR} to take no argument and always expand into
-@samp{(x) - 1 / (x)}).
+The argument for @samp{EXP} is substituted once, as-is, into the
+@samp{if} statement, and once, stringified, into the argument to
+@samp{fprintf}. If @samp{x} were a macro, it would be expanded in the
+@samp{if} statement, but not in the string.
-Note that the @emph{uses} of a macro with arguments can have spaces
-before the left parenthesis; it's the @emph{definition} where it matters
-whether there is a space.
+The @samp{do} and @samp{while (0)} are a kludge to make it possible to
+write @samp{WARN_IF (@var{arg});}, which the resemblance of
+@samp{WARN_IF} to a function would make C programmers want to do; see
+@ref{Swallowing the Semicolon}.
-@node Macro Varargs, Predefined, Function-like Macros, Macros
-@subsection Macros with Variable Numbers of Arguments
-@cindex variable number of arguments
-@cindex macro with variable arguments
-@cindex rest argument (in macro)
+Stringification in C involves more than putting double-quote characters
+around the fragment. The preprocessor backslash-escapes the surrounding
+quotes of string literals, and all backslashes within string and
+character constants, in order to get a valid C string constant with the
+proper contents. Thus, stringifying @samp{@w{p = "foo\n";}} results in
+@t{@w{"p = \"foo\\n\";"}}. However, backslashes that are not inside string
+or character constants are not duplicated: @samp{\n} by itself
+stringifies to @t{"\n"}.
+
+All leading and trailing whitespace in text being stringified is
+ignored. Any sequence of whitespace in the middle of the text is
+converted to a single space in the stringified result. Comments are
+replaced by whitespace long before stringification happens, so they
+never appear in stringified text.
-In the ISO C standard of 1999, a macro can be declared to accept a
-variable number of arguments much as a function can. The syntax for
-defining the macro is similar to that of a function. Here is an
-example:
+There is no way to convert a macro argument into a character constant.
+
+If you want to stringify the result of expansion of a macro argument,
+you have to use two levels of macros.
@example
-#define eprintf(...) fprintf (stderr, __VA_ARGS__)
+#define xstr(s) str(s)
+#define str(s) #s
+#define foo 4
+str (foo)
+ @expansion{} "foo"
+xstr (foo)
+ @expansion{} xstr (4)
+ @expansion{} str (4)
+ @expansion{} "4"
@end example
-Here @samp{@dots{}} is a @dfn{variable argument}. In the invocation of
-such a macro, it represents the zero or more tokens until the closing
-parenthesis that ends the invocation, including any commas. This set of
-tokens replaces the identifier @code{__VA_ARGS__} in the macro body
-wherever it appears. Thus, we have this expansion:
+@code{s} is stringified when it is used in @code{str}, so it is not
+macro-expanded first. But @code{s} is an ordinary argument to
+@code{xstr}, so it is completely macro-expanded before @code{xstr}
+itself is expanded (@pxref{Argument Prescan}). Therefore, by the time
+@code{str} gets to its argument, it has already been macro-expanded.
+
+@node Concatenation
+@section Concatenation
+@cindex concatenation
+@cindex token pasting
+@cindex token concatenation
+@cindex @samp{##} operator
+
+It is often useful to merge two tokens into one while expanding macros.
+This is called @dfn{token pasting} or @dfn{token concatenation}. The
+@samp{##} preprocessing operator performs token pasting. When a macro
+is expanded, the two tokens on either side of each @samp{##} operator
+are combined into a single token, which then replaces the @samp{##} and
+the two original tokens in the macro expansion. Usually both will be
+identifiers, or one will be an identifier and the other a preprocessing
+number. When pasted, they make a longer identifier. This isn't the
+only valid case. It is also possible to concatenate two numbers (or a
+number and a name, such as @samp{1.5} and @samp{e3}) into a number.
+Also, multi-character operators such as @samp{+=} can be formed by
+token pasting.
+
+However, two tokens that don't together form a valid token cannot be
+pasted together. For example, you cannot concatenate @samp{x} with
+@samp{+} in either order. If you try, the preprocessor issues a warning
+and emits the two tokens as if they had been written next to each other.
+It is common to find unnecessary uses of @samp{##} in complex macros.
+If you get this warning, it is likely that you can simply remove the
+@samp{##}.
+
+Both the tokens combined by @samp{##} could come from the macro body,
+but you could just as well write them as one token in the first place.
+Token pasting is most useful when one or both of the tokens comes from a
+macro argument. If either of the tokens next to an @samp{##} is a
+parameter name, it is replaced by its actual argument before @samp{##}
+executes. As with stringification, the actual argument is not
+macro-expanded first. If the argument is empty, that @samp{##} has no
+effect.
+
+Keep in mind that the C preprocessor converts comments to whitespace
+before macros are even considered. Therefore, you cannot create a
+comment by concatenating @samp{/} and @samp{*}. You can put as much
+whitespace between @samp{##} and its operands as you like, including
+comments, and you can put comments in arguments that will be
+concatenated. However, it is an error if @samp{##} appears at either
+end of a macro body.
+
+Consider a C program that interprets named commands. There probably
+needs to be a table of commands, perhaps an array of structures declared
+as follows:
@example
-eprintf ("%s:%d: ", input_file_name, line_number)
-@expansion{}
-fprintf (stderr, "%s:%d: " , input_file_name, line_number)
-@end example
+@group
+struct command
+@{
+ char *name;
+ void (*function) (void);
+@};
+@end group
-Within a @samp{#define} directive, ISO C mandates that the only place
-the identifier @code{__VA_ARGS__} can appear is in the replacement list
-of a variable-argument macro. It may not be used as a macro name, macro
-argument name, or within a different type of macro. It may also be
-forbidden in open text; the standard is ambiguous. We recommend you
-avoid using it except for its defined purpose.
+@group
+struct command commands[] =
+@{
+ @{ "quit", quit_command @},
+ @{ "help", help_command @},
+ @dots{}
+@};
+@end group
+@end example
-If your macro is complicated, you may want a more descriptive name for
-the variable argument than @code{__VA_ARGS__}. GNU cpp permits this, as
-an extension. You may write an argument name immediately before the
-@samp{@dots{}}; that name is used for the variable argument. The
-@code{eprintf} macro above could be written
+It would be cleaner not to have to give each command name twice, once in
+the string constant and once in the function name. A macro which takes the
+name of a command as an argument can make this unnecessary. The string
+constant can be created with stringification, and the function name by
+concatenating the argument with @samp{_command}. Here is how it is done:
@example
-#define eprintf(args...) fprintf (stderr, args)
+#define COMMAND(NAME) @{ #NAME, NAME ## _command @}
+
+struct command commands[] =
+@{
+ COMMAND (quit),
+ COMMAND (help),
+ @dots{}
+@};
@end example
-@noindent
-using this extension. You cannot use @code{__VA_ARGS__} and this
-extension in the same macro.
+@node Variadic Macros
+@section Variadic Macros
+@cindex variable number of arguments
+@cindex macros with variable arguments
+@cindex variadic macros
-We might instead have defined eprintf as follows:
+A macro can be declared to accept a variable number of arguments much as
+a function can. The syntax for defining the macro is similar to that of
+a function. Here is an example:
@example
-#define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__)
+#define eprintf(...) fprintf (stderr, __VA_ARGS__)
@end example
-This formulation looks more descriptive, but cannot be used as flexibly.
-There is no way to produce expanded output of
+This kind of macro is called @dfn{variadic}. When the macro is invoked,
+all the tokens in its argument list after the last named argument (this
+macro has none), including any commas, become the @dfn{variable
+argument}. This sequence of tokens replaces the identifier
+@code{@w{__VA_ARGS__}} in the macro body wherever it appears. Thus, we
+have this expansion:
@example
-fprintf (stderr, "success!\n")
+eprintf ("%s:%d: ", input_file, lineno)
+ @expansion{} fprintf (stderr, "%s:%d: ", input_file, lineno)
@end example
-@noindent
-because, in standard C, you are not allowed to leave the variable
-argument out entirely, and passing an empty argument for the variable
-arguments will not do what you want. Writing
+The variable argument is completely macro-expanded before it is inserted
+into the macro expansion, just like an ordinary argument. You may use
+the @samp{#} and @samp{##} operators to stringify the variable argument
+or to paste its leading or trailing token with another token. (But see
+below for an important special case for @samp{##}.)
+
+If your macro is complicated, you may want a more descriptive name for
+the variable argument than @code{@w{__VA_ARGS__}}. GNU CPP permits
+this, as an extension. You may write an argument name immediately
+before the @samp{@dots{}}; that name is used for the variable argument.
+The @code{eprintf} macro above could be written
@example
-eprintf ("success!\n", )
+#define eprintf(args...) fprintf (stderr, args)
@end example
@noindent
-produces
+using this extension. You cannot use @code{__VA_ARGS__} and this
+extension in the same macro.
+
+You can have named arguments as well as variable arguments in a variadic
+macro. We could define @code{eprintf} like this, instead:
@example
-fprintf (stderr, "success!\n",)
+#define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__)
@end example
-@noindent
-where the extra comma originates from the replacement list and not from
-the arguments to eprintf.
+This formulation looks more descriptive, but unfortunately it is less
+flexible: you must now supply at least one argument after the format
+string. In standard C, you cannot omit the comma separating the named
+argument from the variable arguments. Furthermore, if you leave the
+variable argument empty, you will get a syntax error, because
+there will be an extra comma after the format string.
+
+@example
+eprintf("success!\n", );
+ @expansion{} fprintf(stderr, "success!\n", );
+@end example
-There is another extension in the GNU C preprocessor which deals with
-this difficulty. First, you are allowed to leave the variable argument
-out entirely:
+GNU CPP has a pair of extensions which deal with this problem. First,
+you are allowed to leave the variable argument out entirely:
@example
eprintf ("success!\n")
+ @expansion{} fprintf(stderr, "success!\n", );
@end example
Second, the @samp{##} token paste operator has a special meaning when
@emph{not} happen if you pass an empty argument, nor does it happen if
the token preceding @samp{##} is anything other than a comma.
-Previous versions of the preprocessor implemented this extension much
-more generally. We have restricted it in order to minimize the
-difference from the C standard. @xref{Unreliable Features}.
+@example
+eprintf ("success!\n")
+ @expansion{} fprintf(stderr, "success!\n");
+@end example
+
+C99 mandates that the only place the identifier @code{@w{__VA_ARGS__}}
+can appear is in the replacement list of a variadic macro. It may not
+be used as a macro name, macro argument name, or within a different type
+of macro. It may also be forbidden in open text; the standard is
+ambiguous. We recommend you avoid using it except for its defined
+purpose.
+
+Variadic macros are a new feature in C99. GNU CPP has supported them
+for a long time, but only with a named variable argument
+(@samp{args...}, not @samp{...} and @code{@w{__VA_ARGS__}}). If you are
+concerned with portability to previous versions of GCC, you should use
+only named variable arguments. On the other hand, if you are concerned
+with portability to other conforming implementations of C99, you should
+use only @code{@w{__VA_ARGS__}}.
+
+Previous versions of GNU CPP implemented the comma-deletion extension
+much more generally. We have restricted it in this release to minimize
+the differences from C99. To get the same effect with both this and
+previous versions of GCC, the token preceding the special @samp{##} must
+be a comma, and there must be white space between that comma and
+whatever comes immediately before it:
+
+@example
+#define eprintf(format, args...) fprintf (stderr, format , ##args)
+@end example
+
+@noindent
+@xref{Differences from previous versions}, for the gory details.
-@node Predefined, Stringification, Macro Varargs, Macros
-@subsection Predefined Macros
+@node Predefined Macros
+@section Predefined Macros
@cindex predefined macros
Several object-like macros are predefined; you use them without
-supplying their definitions. They fall into two classes: standard
-macros and system-specific macros.
+supplying their definitions. They fall into three classes: standard,
+common, and system-specific.
+
+In C++, there is a fourth category, the named operators. They act like
+predefined macros, but you cannot undefine them.
@menu
-* Standard Predefined:: Standard predefined macros.
-* Nonstandard Predefined:: Nonstandard predefined macros.
+* Standard Predefined Macros::
+* Common Predefined Macros::
+* System-specific Predefined Macros::
+* C++ Named Operators::
@end menu
-@node Standard Predefined, Nonstandard Predefined, Predefined, Predefined
-@subsubsection Standard Predefined Macros
-@cindex standard predefined macros
+@node Standard Predefined Macros
+@subsection Standard Predefined Macros
+@cindex standard predefined macros.
-The standard predefined macros are available with the same meanings
-regardless of the machine or operating system on which you are using GNU
-C@. Their names all start and end with double underscores. Those
-preceding @code{__GNUC__} in this table are standardized by ISO C; the
-rest are GNU C extensions.
+The standard predefined macros are specified by the C and/or C++
+language standards, so they are available with all compilers that
+implement those standards. Older compilers may not provide all of
+them. Their names all start with double underscores.
@table @code
@item __FILE__
-@findex __FILE__
This macro expands to the name of the current input file, in the form of
-a C string constant. The precise name returned is the one that was
-specified in @samp{#include} or as the input file name argument. For
-example, @samp{"/usr/local/include/myheader.h"} is a possible expansion
-of this macro.
+a C string constant. This is the path by which the preprocessor opened
+the file, not the short name specified in @samp{#include} or as the
+input file name argument. For example,
+@samp{"/usr/local/include/myheader.h"} is a possible expansion of this
+macro.
@item __LINE__
-@findex __LINE__
This macro expands to the current input line number, in the form of a
decimal integer constant. While we call it a predefined macro, it's
a pretty strange macro, since its ``definition'' changes with each
new line of source code.
+@end table
-This and @samp{__FILE__} are useful in generating an error message to
-report an inconsistency detected by the program; the message can state
-the source line at which the inconsistency was detected. For example,
+@samp{__FILE__} and @samp{__LINE__} are useful in generating an error
+message to report an inconsistency detected by the program; the message
+can state the source line at which the inconsistency was detected. For
+example,
-@smallexample
+@example
fprintf (stderr, "Internal error: "
"negative string length "
"%d at %s, line %d.",
length, __FILE__, __LINE__);
-@end smallexample
+@end example
-A @samp{#include} directive changes the expansions of @samp{__FILE__}
+An @samp{#include} directive changes the expansions of @samp{__FILE__}
and @samp{__LINE__} to correspond to the included file. At the end of
that file, when processing resumes on the input file that contained
the @samp{#include} directive, the expansions of @samp{__FILE__} and
@samp{#include} (but @samp{__LINE__} is then incremented by one as
processing moves to the line after the @samp{#include}).
-The expansions of both @samp{__FILE__} and @samp{__LINE__} are altered
-if a @samp{#line} directive is used. @xref{Line Control}.
+A @samp{#line} directive changes @samp{__LINE__}, and may change
+@samp{__FILE__} as well. @xref{Line Control}.
+
+C99 introduces @samp{__func__}, and GCC has provided @samp{__FUNCTION__}
+for a long time. Both of these are strings containing the name of the
+current function (there are slight semantic differences; see the GCC
+manual). Neither of them is a macro; the preprocessor does not know the
+name of the current function. They tend to be useful in conjunction
+with @samp{__FILE__} and @samp{__LINE__}, though.
+
+@table @code
@item __DATE__
-@findex __DATE__
-This macro expands to a string constant that describes the date on
-which the preprocessor is being run. The string constant contains
-eleven characters and looks like @w{@samp{"Feb 1 1996"}}.
-@c After reformatting the above, check that the date remains `Feb 1 1996',
-@c all on one line, with two spaces between the `Feb' and the `1'.
+This macro expands to a string constant that describes the date on which
+the preprocessor is being run. The string constant contains eleven
+characters and looks like @w{@samp{"Feb 12 1996"}}. If the day of the
+month is less than 10, it is padded with a space on the left.
@item __TIME__
-@findex __TIME__
This macro expands to a string constant that describes the time at
which the preprocessor is being run. The string constant contains
eight characters and looks like @samp{"23:59:01"}.
@item __STDC__
-@findex __STDC__
-This macro expands to the constant 1, to signify that this is ISO
-Standard C@. (Whether that is actually true depends on what C compiler
-will operate on the output from the preprocessor.)
-
-On some hosts, system include files use a different convention, where
-@samp{__STDC__} is normally 0, but is 1 if the user specifies strict
-conformance to the C Standard. The preprocessor follows the host
-convention when processing system include files, but when processing
-user files it follows the usual GNU C convention.
-
-This macro is not defined if the @samp{-traditional} option is used.
+In normal operation, this macro expands to the constant 1, to signify
+that this compiler conforms to ISO Standard C@. If GNU CPP is used with
+a compiler other than GNU CC, this is not necessarily true; however, the
+preprocessor always conforms to the standard, unless the
+@option{-traditional} option is used.
+
+This macro is not defined if the @option{-traditional} option is used.
+
+On some hosts, the system compiler uses a different convention, where
+@code{__STDC__} is normally 0, but is 1 if the user specifies strict
+conformance to the C Standard. GNU CPP follows the host convention when
+processing system header files, but when processing user files
+@code{__STDC__} is always 1. This has been reported to cause problems;
+for instance, some versions of Solaris provide X Windows headers that
+expect @code{__STDC__} to be either undefined or 1. You may be able to
+work around this sort of problem by using an @option{-I} option to
+cancel treatment of those headers as system headers. @xref{Invocation}.
@item __STDC_VERSION__
-@findex __STDC_VERSION__
This macro expands to the C Standard's version number, a long integer
constant of the form @samp{@var{yyyy}@var{mm}L} where @var{yyyy} and
@var{mm} are the year and month of the Standard version. This signifies
-which version of the C Standard the preprocessor conforms to. Like
-@samp{__STDC__}, whether this version number is accurate for the entire
-implementation depends on what C compiler will operate on the output
-from the preprocessor.
+which version of the C Standard the compiler conforms to. Like
+@samp{__STDC__}, this is not necessarily accurate for the entire
+implementation, unless GNU CPP is being used with GNU CC.
-This macro is not defined if the @samp{-traditional} option is used.
+The value @samp{199409L} signifies the 1989 C standard as amended in
+1994, which is the current default; the value @samp{199901L} signifies
+the 1999 revision of the C standard. Support for the 1999 revision is
+not yet complete.
-@item __GNUC__
-@findex __GNUC__
-This macro is defined if and only if this is GNU C@. This macro is
-defined only when the entire GNU C compiler is in use; if you invoke the
-preprocessor directly, @samp{__GNUC__} is undefined. The value
-identifies the major version number of GNU CC (@samp{1} for GNU CC
-version 1, which is now obsolete, and @samp{2} for version 2).
-
-@item __GNUC_MINOR__
-@findex __GNUC_MINOR__
-The macro contains the minor version number of the compiler. This can
-be used to work around differences between different releases of the
-compiler (for example, if GCC 2.6.x is known to support a feature, you
-can test for @code{__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 6)}).
-
-@item __GNUC_PATCHLEVEL__
-@findex __GNUC_PATCHLEVEL__
-This macro contains the patch level of the compiler. This can be
-used to work around differences between different patch level releases
-of the compiler (for example, if GCC 2.6.2 is known to contain a bug,
-whereas GCC 2.6.3 contains a fix, and you have code which can workaround
-the problem depending on whether the bug is fixed or not, you can test for
-@code{__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ > 6) ||
-(__GNUC__ == 2 && __GNUC_MINOR__ == 6 && __GNUC_PATCHLEVEL__ >= 3)}).
+This macro is not defined if the @option{-traditional} option is used, nor
+when compiling C++ or Objective C@.
-@item __GNUG__
-@findex __GNUG__
-The GNU C compiler defines this when the compilation language is
-C++; use @samp{__GNUG__} to distinguish between GNU C and GNU
-C++.
+@item __STDC_HOSTED__
+This macro is defined, with value 1, if the compiler's target is a
+@dfn{hosted environment}. A hosted environment has the complete
+facilities of the standard C library available.
@item __cplusplus
-@findex __cplusplus
-The ISO standard for C++ requires predefining this variable. You can
-use @samp{__cplusplus} to test whether a header is compiled by a C
-compiler or a C++ compiler. The compiler currently uses a value of
-@samp{1}, instead of the value @samp{199711L}, which would indicate full
-conformance with the standard.
+This macro is defined when the C++ compiler is in use. You can use
+@samp{__cplusplus} to test whether a header is compiled by a C compiler
+or a C++ compiler. This macro is similar to @samp{__STDC_VERSION__}, in
+that it expands to a version number. A fully conforming implementation
+of the 1998 C++ standard will define this macro to @samp{199711L}. The
+GNU C++ compiler is not yet fully conforming, so it uses @samp{1}
+instead. We hope to complete our implementation in the near future.
+
+@end table
+
+@node Common Predefined Macros
+@subsection Common Predefined Macros
+@cindex common predefined macros
+
+The common predefined macros are GNU C extensions. They are available
+with the same meanings regardless of the machine or operating system on
+which you are using GNU C@. Their names all start with double
+underscores.
+
+@table @code
+
+@item __GNUC__
+@itemx __GNUC_MINOR__
+@itemx __GNUC_PATCHLEVEL__
+These macros are defined by all GNU compilers that use the C
+preprocessor: C, C++, and Objective C. Their values are the major
+version, minor version, and patch level of the compiler, as integer
+constants. For example, GCC 3.2.1 will define @code{__GNUC__} to 3,
+@code{__GNUC_MINOR__} to 2, and @code{__GNUC_PATCHLEVEL__} to 1. They
+are defined only when the entire compiler is in use; if you invoke the
+preprocessor directly, they are not defined.
+
+
+
+@code{__GNUC_PATCHLEVEL__} is new to GCC 3.0; it is also present in the
+widely-used development snapshots leading up to 3.0 (which identify
+themselves as GCC 2.96 or 2.97, depending on which snapshot you have).
+
+If all you need to know is whether or not your program is being compiled
+by GCC, you can simply test @code{__GNUC__}. If you need to write code
+which depends on a specific version, you must be more careful. Each
+time the minor version is increased, the patch level is reset to zero;
+each time the major version is increased (which happens rarely), the
+minor version and patch level are reset. The simplest way to write the
+conditional is like this:
+
+@example
+/* @r{Test for GCC > 3.2.0} */
+#if __GNUC__ > 3 || __GNUC_MINOR__ > 2 \
+ || __GNUC_PATCHLEVEL__ > 0
+@end example
+
+@noindent
+This takes advantage of the rule that an undefined macro evaluates to
+zero in an @samp{#if}. The conditional will be false if
+@code{__GNUC__} is not defined (that is, if you are not using @w{GNU CC}).
+
+@item __GNUG__
+The GNU C++ compiler defines this. Testing it is equivalent to
+testing @samp{(__GNUC__ && __cplusplus)}.
@item __STRICT_ANSI__
-@findex __STRICT_ANSI__
GNU C defines this macro if and only if the @option{-ansi} switch, or a
@option{-std} switch specifying strict conformance to some version of ISO C,
was specified when GNU C was invoked. Its definition is the null string.
-This macro exists primarily to direct certain GNU header files not to
-define certain traditional Unix constructs which are incompatible with
-ISO C@.
+This macro exists primarily to direct GNU libc's header files to
+restrict their definitions to the minimal set found in the 1989 C
+standard.
@item __BASE_FILE__
-@findex __BASE_FILE__
This macro expands to the name of the main input file, in the form
of a C string constant. This is the source file that was specified
on the command line of the preprocessor or C compiler.
@item __INCLUDE_LEVEL__
-@findex __INCLUDE_LEVEL_
This macro expands to a decimal integer constant that represents the
depth of nesting in include files. The value of this macro is
incremented on every @samp{#include} directive and decremented at the
base file specified on the command line.
@item __VERSION__
-@findex __VERSION__
-This macro expands to a string constant which describes the version
-number of GNU C@. The string is normally a sequence of decimal numbers
-separated by periods, such as @samp{"2.6.0"}.
+This macro expands to a string constant which describes the version of
+the compiler in use. You should not rely on its contents having any
+particular form, but it can be counted on to contain at least the
+release number.
@item __OPTIMIZE__
-@findex __OPTIMIZE__
-GNU CC defines this macro in optimizing compilations. It causes certain
-GNU header files to define alternative macro definitions for some system
-library functions. You should not refer to or test the definition of
-this macro unless you make very sure that programs will execute with the
-same effect regardless.
-
-@item __OPTIMIZE_SIZE__
-@findex __OPTIMIZE_SIZE__
-GNU CC defines this macro when optimizing for size with @samp{-Os}. It
-causes certain GNU header files to define alternative macro definitions
-for some system library functions. You should not refer to or test the
-definition of this macro unless you make very sure that programs will
-execute with the same effect regardless.
-
-@item __NO_INLINE__
-@findex __NO_INLINE__
-GNU CC defines this macro if it will not attempt to inline functions
-with @samp{inline} keyword (either when not optimizing or when inlining
-has been explicitely forbidden through @samp{-fno-inline}). It causes
-certain GNU header files to define alternative macro definitions for some
-system library functions. You should not refer to or test the definition
-of this macro unless you make very sure that programs will execute with
-the same effect regardless.
+@itemx __OPTIMIZE_SIZE__
+@itemx __NO_INLINE__
+These macros describe the compilation mode. @code{__OPTIMIZE__} is
+defined in all optimizing compilations. @code{__OPTIMIZE_SIZE__} is
+defined if the compiler is optimizing for size, not speed.
+@code{__NO_INLINE__} is defined if no functions will be inlined into
+their callers (when not optimizing, or when inlining has been
+specifically disabled by @option{-fno-inline}).
+
+These macros cause certain GNU header files to provide optimized
+definitions, using macros or inline functions, of system library
+functions. You should not use these macros in any way unless you make
+sure that programs will execute with the same effect whether or not they
+are defined. If they are defined, their value is 1.
@item __CHAR_UNSIGNED__
-@findex __CHAR_UNSIGNED__
GNU C defines this macro if and only if the data type @code{char} is
unsigned on the target machine. It exists to cause the standard header
-file @file{limits.h} to work correctly. You should not refer to this
-macro yourself; instead, refer to the standard macros defined in
-@file{limits.h}. The preprocessor uses this macro to determine whether
-or not to sign-extend large character constants written in octal; see
-@ref{#if Directive,,The @samp{#if} Directive}.
+file @file{limits.h} to work correctly. You should not use this macro
+yourself; instead, refer to the standard macros defined in @file{limits.h}.
@item __REGISTER_PREFIX__
-@findex __REGISTER_PREFIX__
-This macro expands to a string (not a string constant) describing the
-prefix applied to CPU registers in assembler code. You can use it to
-write assembler code that is usable in multiple environments. For
-example, in the @samp{m68k-aout} environment it expands to the null
-string, but in the @samp{m68k-coff} environment it expands to the string
-@samp{%}.
+This macro expands to a single token (not a string constant) which is
+the prefix applied to CPU register names in assembly language for this
+target. You can use it to write assembly that is usable in multiple
+environments. For example, in the @samp{m68k-aout} environment it
+expands to nothing, but in the @samp{m68k-coff} environment it expands
+to a single @samp{%}.
@item __USER_LABEL_PREFIX__
-@findex __USER_LABEL_PREFIX__
-Similar to @code{__REGISTER_PREFIX__}, but describes the prefix applied
-to user generated labels in assembler code. For example, in the
-@samp{m68k-aout} environment it expands to the string @samp{_}, but in
-the @samp{m68k-coff} environment it expands to the null string. This
-does not work with the @samp{-mno-underscores} option that the i386
-OSF/rose and m88k targets provide nor with the @samp{-mcall*} options of
-the rs6000 System V Release 4 target.
-@end table
-
-@node Nonstandard Predefined,, Standard Predefined, Predefined
-@subsubsection Nonstandard Predefined Macros
-
-The C preprocessor normally has several predefined macros that vary
-between machines because their purpose is to indicate what type of
-system and machine is in use. This manual, being for all systems and
-machines, cannot tell you exactly what their names are; instead, we
-offer a list of some typical ones. You can use @samp{cpp -dM} to see
-the values of predefined macros; see @ref{Invocation}.
-
-Some nonstandard predefined macros describe the operating system in use,
-with more or less specificity. For example,
-
-@table @code
-@item unix
-@findex unix
-@samp{unix} is normally predefined on all Unix systems.
-
-@item BSD
-@findex BSD
-@samp{BSD} is predefined on recent versions of Berkeley Unix
-(perhaps only in version 4.3).
-@end table
-
-Other nonstandard predefined macros describe the kind of CPU, with more or
-less specificity. For example,
-
-@table @code
-@item vax
-@findex vax
-@samp{vax} is predefined on Vax computers.
-
-@item mc68000
-@findex mc68000
-@samp{mc68000} is predefined on most computers whose CPU is a Motorola
-68000, 68010 or 68020.
-
-@item m68k
-@findex m68k
-@samp{m68k} is also predefined on most computers whose CPU is a 68000,
-68010 or 68020; however, some makers use @samp{mc68000} and some use
-@samp{m68k}. Some predefine both names. What happens in GNU C
-depends on the system you are using it on.
-
-@item M68020
-@findex M68020
-@samp{M68020} has been observed to be predefined on some systems that
-use 68020 CPUs --- in addition to @samp{mc68000} and @samp{m68k}, which
-are less specific.
-
-@item _AM29K
-@findex _AM29K
-@itemx _AM29000
-@findex _AM29000
-Both @samp{_AM29K} and @samp{_AM29000} are predefined for the AMD 29000
-CPU family.
-
-@item ns32000
-@findex ns32000
-@samp{ns32000} is predefined on computers which use the National
-Semiconductor 32000 series CPU.
-@end table
-
-Yet other nonstandard predefined macros describe the manufacturer of
-the system. For example,
+This macro expands to a single token which is the the prefix applied to
+user labels (symbols visible to C code) in assembly. For example, in
+the @samp{m68k-aout} environment it expands to an @samp{_}, but in the
+@samp{m68k-coff} environment it expands to nothing.
+
+This macro will have the correct definition even if
+@option{-f(no-)underscores} is in use, but it will not be correct if
+target-specific options that adjust this prefix are used (e.g. the
+OSF/rose @option{-mno-underscores} option).
+
+@item __SIZE_TYPE__
+@itemx __PTRDIFF_TYPE__
+@itemx __WCHAR_TYPE__
+@itemx __WINT_TYPE__
+These macros are defined to the correct underlying types for the
+@code{size_t}, @code{ptrdiff_t}, @code{wchar_t}, and @code{wint_t}
+typedefs, respectively. They exist to make the standard header files
+@file{stddef.h} and @file{wchar.h} work correctly. You should not use
+these macros directly; instead, include the appropriate headers and use
+the typedefs.
-@table @code
-@item sun
-@findex sun
-@samp{sun} is predefined on all models of Sun computers.
-
-@item pyr
-@findex pyr
-@samp{pyr} is predefined on all models of Pyramid computers.
-
-@item sequent
-@findex sequent
-@samp{sequent} is predefined on all models of Sequent computers.
@end table
-These predefined symbols are not only nonstandard, they are contrary to the
-ISO standard because their names do not start with underscores.
-Therefore, the option @samp{-ansi} inhibits the definition of these
-symbols.
-
-This tends to make @samp{-ansi} useless, since many programs depend on
-the customary nonstandard predefined symbols. Even system header files
-check them and will generate incorrect declarations if they do not find
-the names that are expected. You might think that the header files
-supplied for the Uglix computer would not need to test what machine they
-are running on, because they can simply assume it is the Uglix; but
-often they do, and they do so using the customary names. As a result,
-very few C programs will compile with @samp{-ansi}. We intend to avoid
-such problems on the GNU system.
-
-What, then, should you do in an ISO C program to test the type of machine
-it will run on?
-
-GNU C offers a parallel series of symbols for this purpose, whose names
-are made from the customary ones by adding @samp{__} at the beginning
-and end. Thus, the symbol @code{__vax__} would be available on a Vax,
-and so on.
-
-The set of nonstandard predefined names in the GNU C preprocessor is
-controlled (when @code{cpp} is itself compiled) by the macro
-@samp{CPP_PREDEFINES}, which should be a string containing @samp{-D}
-options, separated by spaces. For example, on the Sun 3, we use the
-following definition:
-
-@example
-#define CPP_PREDEFINES "-Dmc68000 -Dsun -Dunix -Dm68k"
-@end example
-
-@noindent
-This macro is usually specified in @file{tm.h}.
-
-@node Stringification, Concatenation, Predefined, Macros
-@subsection Stringification
-
-@cindex stringification
-@dfn{Stringification} means turning a sequence of preprocessing tokens
-into a string literal. For example, stringifying @samp{foo (z)} results
-in @samp{"foo (z)"}.
-
-In the C preprocessor, stringification is possible when macro arguments
-are substituted during macro expansion. When a parameter appears
-preceded by a @samp{#} token in the replacement list of a function-like
-macro, it indicates that both tokens should be replaced with the
-stringification of the corresponding argument during expansion. The
-same argument may be substituted in other places in the definition
-without stringification if the argument name appears in those places
-with no preceding @samp{#}.
-
-Here is an example of a macro definition that uses stringification:
-
-@smallexample
-@group
-#define WARN_IF(EXP) \
-do @{ if (EXP) \
- fprintf (stderr, "Warning: " #EXP "\n"); @} \
-while (0)
-@end group
-@end smallexample
-
-@noindent
-Here the argument for @samp{EXP} is substituted once, as-is, into the
-@samp{if} statement, and once, stringified, into the argument to
-@samp{fprintf}. The @samp{do} and @samp{while (0)} are a kludge to make
-it possible to write @samp{WARN_IF (@var{arg});}, which the resemblance
-of @samp{WARN_IF} to a function would make C programmers want to do; see
-@ref{Swallow Semicolon}.
-
-The stringification feature is limited to transforming the tokens of a
-macro argument into a string constant: there is no way to combine the
-argument with surrounding text and stringify it all together. The
-example above shows how an equivalent result can be obtained in ISO
-Standard C, using the fact that adjacent string constants are
-concatenated by the C compiler to form a single string constant. The
-preprocessor stringifies the actual value of @samp{EXP} into a separate
-string constant, resulting in text like
-
-@smallexample
-@group
-do @{ if (x == 0) \
- fprintf (stderr, "Warning: " "x == 0" "\n"); @} \
-while (0)
-@end group
-@end smallexample
-
-@noindent
-but the compiler then sees three consecutive string constants and
-concatenates them into one, producing effectively
-
-@smallexample
-do @{ if (x == 0) \
- fprintf (stderr, "Warning: x == 0\n"); @} \
-while (0)
-@end smallexample
-
-Stringification in C involves more than putting double-quote characters
-around the fragment. The preprocessor backslash-escapes the surrounding
-quotes of string literals, and all backslashes within string and
-character constants, in order to get a valid C string constant with the
-proper contents. Thus, stringifying @samp{p = "foo\n";} results in
-@samp{"p = \"foo\\n\";"}. However, backslashes that are not inside
-string or character constants are not duplicated: @samp{\n} by itself
-stringifies to @samp{"\n"}.
-
-Whitespace (including comments) in the text being stringified is handled
-according to precise rules. All leading and trailing whitespace is
-ignored. Any sequence of whitespace in the middle of the text is
-converted to a single space in the stringified result.
-
-@node Concatenation, Undefining, Stringification, Macros
-@subsection Concatenation
-@cindex concatenation
-@cindex @samp{##}
-@dfn{Concatenation} means joining two strings into one. In the context
-of macro expansion, concatenation refers to joining two preprocessing
-tokens to form one. In particular, a token of a macro argument can be
-concatenated with another argument's token or with fixed text to produce
-a longer name. The longer name might be the name of a function,
-variable, type, or a C keyword; it might even be the name of another
-macro, in which case it will be expanded.
-
-When you define a function-like or object-like macro, you request
-concatenation with the special operator @samp{##} in the macro's
-replacement list. When the macro is called, any arguments are
-substituted without performing macro expansion, every @samp{##} operator
-is deleted, and the two tokens on either side of it are concatenated to
-form a single token.
-
-Consider a C program that interprets named commands. There probably needs
-to be a table of commands, perhaps an array of structures declared as
-follows:
-
-@example
-struct command
-@{
- char *name;
- void (*function) ();
-@};
-
-struct command commands[] =
-@{
- @{ "quit", quit_command@},
- @{ "help", help_command@},
- @dots{}
-@};
-@end example
-
-It would be cleaner not to have to give each command name twice, once in
-the string constant and once in the function name. A macro which takes the
-name of a command as an argument can make this unnecessary. The string
-constant can be created with stringification, and the function name by
-concatenating the argument with @samp{_command}. Here is how it is done:
-
-@example
-#define COMMAND(NAME) @{ #NAME, NAME ## _command @}
-
-struct command commands[] =
-@{
- COMMAND (quit),
- COMMAND (help),
- @dots{}
-@};
-@end example
-
-The usual case of concatenation is concatenating two names (or a name
-and a number) into a longer name. This isn't the only valid case.
-It is also possible to concatenate two numbers (or a number and a name,
-such as @samp{1.5} and @samp{e3}) into a number. Also, multi-character
-operators such as @samp{+=} can be formed by concatenation. However,
-two tokens that don't together form a valid token cannot be
-concatenated. For example, concatenation of @samp{x} on one side and
-@samp{+} on the other is not meaningful because those two tokens do not
-form a valid preprocessing token when concatenated. UNDEFINED
-
-Keep in mind that the C preprocessor converts comments to whitespace
-before macros are even considered. Therefore, you cannot create a
-comment by concatenating @samp{/} and @samp{*}: the @samp{/*} sequence
-that starts a comment is not a token, but rather the beginning of a
-comment. You can freely use comments next to @samp{##} in a macro
-definition, or in arguments that will be concatenated, because the
-comments will be converted to spaces at first sight, and concatenation
-operates on tokens and so ignores whitespace.
-
-@node Undefining, Redefining, Concatenation, Macros
-@subsection Undefining Macros
-
+@node System-specific Predefined Macros
+@subsection System-specific Predefined Macros
+
+@cindex system-specific predefined macros
+@cindex predefined macros, system-specific
+@cindex reserved namespace
+
+The C preprocessor normally predefines several macros that indicate what
+type of system and machine is in use. They are obviously different on
+each target supported by GNU C@. This manual, being for all systems and
+machines, cannot tell you what their names are, but you can use
+@samp{cpp -dM} to see them all. @xref{Invocation}. All system-specific
+predefined macros expand to the constant 1, so you can test them with
+either @samp{#ifdef} or @samp{#if}.
+
+The C standard requires that all system-specific macros be part of the
+@dfn{reserved namespace}. All names which begin with two underscores,
+or an underscore and a capital letter, are reserved for the compiler and
+library to use as they wish. However, historically system-specific
+macros have had names with no special prefix; for instance, it is common
+to find @samp{unix} defined on Unix systems. For all such macros, GCC
+provides a parallel macro with two underscores added at the beginning
+and the end. If @samp{unix} is defined, @samp{__unix__} will be defined
+too. There will never be more than two underscores; the parallel of
+@samp{_mips} is @samp{__mips__}.
+
+When the @option{-ansi} option, or any @option{-std} option that
+requests strict conformance, is given to the compiler, all the
+system-specific predefined macros outside the reserved namespace are
+suppressed. The parallel macros, inside the reserved namespace, remain
+defined.
+
+We are slowly phasing out all predefined macros which are outside the
+reserved namespace. You should never use them in new programs, and we
+encourage you to correct older code to use the parallel macros whenever
+you find it. We don't recommend you use the system-specific macros that
+are in the reserved namespace, either. It is better in the long run to
+check specifically for features you need, using a tool such as
+@docref{autoconf}.
+
+@node C++ Named Operators
+@subsection C++ Named Operators
+@cindex named operators
+@cindex C++ named operators
+@cindex iso646.h
+
+In C++, there are eleven keywords which are simply alternate spellings
+of operators normally written with punctuation. These keywords are
+treated as such even in the preprocessor. They function as operators in
+@samp{#if}, and they cannot be defined as macros or poisoned. In C, you
+can request that those keywords take their C++ meaning by including
+@file{iso646.h}. That header defines each one as a normal object-like
+macro expanding to the appropriate punctuator.
+
+These are the named operators and their corresponding punctuators:
+
+@multitable {Named Operator} {Punctuator}
+@item Named Operator @tab Punctuator
+@item @code{and} @tab @code{&&}
+@item @code{and_eq} @tab @code{&=}
+@item @code{bitand} @tab @code{&}
+@item @code{bitor} @tab @code{|}
+@item @code{compl} @tab @code{~}
+@item @code{not} @tab @code{!}
+@item @code{not_eq} @tab @code{!=}
+@item @code{or} @tab @code{||}
+@item @code{or_eq} @tab @code{|=}
+@item @code{xor} @tab @code{^}
+@item @code{xor_eq} @tab @code{^=}
+@end multitable
+
+@node Undefining and Redefining Macros
+@section Undefining and Redefining Macros
@cindex undefining macros
-To @dfn{undefine} a macro means to cancel its definition. This is done
-with the @samp{#undef} directive. @samp{#undef} is followed by the macro
-name to be undefined.
-
-Like definition, undefinition occurs at a specific point in the source
-file, and it applies starting from that point. The name ceases to be a
-macro name, and from that point on it is treated by the preprocessor as
-if it had never been a macro name.
+@cindex redefining macros
+@findex #undef
-For example,
+If a macro ceases to be useful, it may be @dfn{undefined} with the
+@samp{#undef} directive. @samp{#undef} takes a single argument, the
+name of the macro to undefine. You use the bare macro name, even if the
+macro is function-like. It is an error if anything appears on the line
+after the macro name. @samp{#undef} has no effect if the name is not a
+macro.
@example
#define FOO 4
-x = FOO;
+x = FOO; @expansion{} x = 4;
#undef FOO
-x = FOO;
-@end example
-
-@noindent
-expands into
-
-@example
-x = 4;
-
-x = FOO;
+x = FOO; @expansion{} x = FOO;
@end example
-@noindent
-In this example, @samp{FOO} had better be a variable or function as well
-as (temporarily) a macro, in order for the result of the expansion to be
-valid C code.
-
-The same form of @samp{#undef} directive will cancel definitions with
-arguments or definitions that don't expect arguments. The @samp{#undef}
-directive has no effect when used on a name not currently defined as a
-macro.
-
-@node Redefining, Poisoning, Undefining, Macros
-@subsection Redefining Macros
-
-@cindex redefining macros
-@dfn{Redefining} a macro means defining (with @samp{#define}) a name that
-is already defined as a macro.
-
-A redefinition is trivial if the new definition is transparently
-identical to the old one. You probably wouldn't deliberately write a
-trivial redefinition, but they can happen automatically when a header
-file is included more than once (@pxref{Header Files}), so they are
-accepted silently and without effect.
-
-Nontrivial redefinition is considered likely to be an error, so it
-provokes a warning message from the preprocessor. However, sometimes it
-is useful to change the definition of a macro in mid-compilation. You
-can inhibit the warning by undefining the macro with @samp{#undef}
-before the second definition.
-
-In order for a redefinition to be trivial, the parameter names must
-match and be in the same order, and the new replacement list must
-exactly match the one already in effect, with two possible exceptions:
+Once a macro has been undefined, that identifier may be @dfn{redefined}
+as a macro by a subsequent @samp{#define} directive. The new definition
+need not have any resemblance to the old definition.
+However, if an identifier which is currently a macro is redefined, then
+the new definition must be @dfn{effectively the same} as the old one.
+Two macro definitions are effectively the same if:
@itemize @bullet
-@item
-Whitespace may be added or deleted at the beginning or the end of the
-replacement list. In a sense this is vacuous, since strictly such
-whitespace doesn't form part of the macro's expansion.
-
-@item
-Between tokens in the expansion, any two forms of whitespace are
-considered equivalent. In particular, whitespace may not be eliminated
-entirely, nor may it be added where there previously wasn't any.
+@item Both are the same type of macro (object- or function-like).
+@item All the tokens of the replacement list are the same.
+@item If there are any parameters, they are the same.
+@item Whitespace appears in the same places in both. It need not be
+exactly the same amount of whitespace, though. Remember that comments
+count as whitespace.
@end itemize
-Recall that a comment counts as whitespace.
-
-As a particular case of the above, you may not redefine an object-like
-macro as a function-like macro, and vice-versa.
-
-@node Poisoning, Macro Pitfalls, Redefining, Macros
-@subsection Poisoning Macros
-@cindex poisoning macros
-@findex #pragma GCC poison
-
-Sometimes, there is an identifier that you want to remove completely
-from your program, and make sure that it never creeps back in. To
-enforce this, the @samp{#pragma GCC poison} directive can be used.
-@samp{#pragma GCC poison} is followed by a list of identifiers to
-poison, and takes effect for the rest of the source. You cannot
-@samp{#undef} a poisoned identifier or test to see if it's defined with
-@samp{#ifdef}.
-
-For example,
-
+@noindent
+These definitions are effectively the same:
@example
-#pragma GCC poison printf sprintf fprintf
-sprintf(some_string, "hello");
+#define FOUR (2 + 2)
+#define FOUR (2 + 2)
+#define FOUR (2 /* two */ + 2)
@end example
-
@noindent
-will produce an error.
-
-Note, if the poisoned identifier appears through the result of macro
-expansion it @emph{won't} cause an error. So if you poison an
-identifier you need not worry about system headers defining macros that
-use it.
-
-For example,
-
+but these are not:
@example
-#define strrchr rindex
-#pragma GCC poison rindex
-strrchr(some_string, 'h');
+#define FOUR (2 + 2)
+#define FOUR ( 2+2 )
+#define FOUR (2 * 2)
+#define FOUR(score,and,seven,years,ago) (2 + 2)
@end example
-@noindent
-will not produce an error.
+If a macro is redefined with a definition that is not effectively the
+same as the old one, the preprocessor issues a warning and changes the
+macro to use the new definition. If the new definition is effectively
+the same, the redefinition is silently ignored. This allows, for
+instance, two different headers to define a common macro. The compiler
+will only complain if the definitions do not match.
-@node Macro Pitfalls,, Poisoning, Macros
-@subsection Pitfalls and Subtleties of Macros
+@node Macro Pitfalls
+@section Macro Pitfalls
@cindex problems with macros
@cindex pitfalls of macros
counterintuitive consequences that you must watch out for.
@menu
-* Misnesting:: Macros can contain unmatched parentheses.
-* Macro Parentheses:: Why apparently superfluous parentheses
- may be necessary to avoid incorrect grouping.
-* Swallow Semicolon:: Macros that look like functions
- but expand into compound statements.
-* Side Effects:: Unsafe macros that cause trouble when
- arguments contain side effects.
-* Self-Reference:: Macros whose definitions use the macros' own names.
-* Argument Prescan:: Arguments are checked for macro calls before they
- are substituted.
-* Cascaded Macros:: Macros whose definitions use other macros.
-* Newlines in Args:: Sometimes line numbers get confused.
+* Misnesting::
+* Operator Precedence Problems::
+* Swallowing the Semicolon::
+* Duplication of Side Effects::
+* Self-Referential Macros::
+* Argument Prescan::
+* Newlines in Arguments::
@end menu
-@node Misnesting, Macro Parentheses, Macro Pitfalls, Macro Pitfalls
-@subsubsection Improperly Nested Constructs
+@node Misnesting
+@subsection Misnesting
-Recall that when a macro is called with arguments, the arguments are
-substituted into the macro body and the result is checked, together with
-the rest of the input file, for more macro calls.
-
-It is possible to piece together a macro call coming partially from the
-macro body and partially from the arguments. For example,
+When a macro is called with arguments, the arguments are substituted
+into the macro body and the result is checked, together with the rest of
+the input file, for more macro calls. It is possible to piece together
+a macro call coming partially from the macro body and partially from the
+arguments. For example,
@example
-#define double(x) (2*(x))
+#define twice(x) (2*(x))
#define call_with_1(x) x(1)
+call_with_1 (twice)
+ @expansion{} twice(1)
+ @expansion{} (2*(1))
@end example
-@noindent
-would expand @samp{call_with_1 (double)} into @samp{(2*(1))}.
-
Macro definitions do not have to have balanced parentheses. By writing
an unbalanced open parenthesis in a macro body, it is possible to create
a macro call that begins inside the macro body but ends outside of it.
#define strange(file) fprintf (file, "%s %d",
@dots{}
strange(stderr) p, 35)
+ @expansion{} fprintf (stderr, "%s %d", p, 35)
@end example
-@noindent
-This bizarre example expands to @samp{fprintf (stderr, "%s %d", p, 35)}!
+The ability to piece together a macro call can be useful, but the use of
+unbalanced open parentheses in a macro body is just confusing, and
+should be avoided.
-@node Macro Parentheses, Swallow Semicolon, Misnesting, Macro Pitfalls
-@subsubsection Unintended Grouping of Arithmetic
+@node Operator Precedence Problems
+@subsection Operator Precedence Problems
@cindex parentheses in macro bodies
You may have noticed that in most of the macro definition examples shown
@example
a = ceil_div (b & c, sizeof (int));
+ @expansion{} a = (b & c + sizeof (int) - 1) / sizeof (int);
@end example
@noindent
-This expands into
-
-@example
-a = (b & c + sizeof (int) - 1) / sizeof (int);
-@end example
-
-@noindent
-which does not do what is intended. The operator-precedence rules of
+This does not do what is intended. The operator-precedence rules of
C make it equivalent to this:
@example
precedence rules have put the division outside the @samp{sizeof} when it
was intended to be inside.
-Parentheses around the entire macro definition can prevent such
-problems. Here, then, is the recommended way to define @samp{ceil_div}:
+Parentheses around the entire macro definition prevent such problems.
+Here, then, is the recommended way to define @samp{ceil_div}:
@example
#define ceil_div(x, y) (((x) + (y) - 1) / (y))
@end example
-@node Swallow Semicolon, Side Effects, Macro Parentheses, Macro Pitfalls
-@subsubsection Swallowing the Semicolon
-
+@node Swallowing the Semicolon
+@subsection Swallowing the Semicolon
@cindex semicolons (after macro calls)
+
Often it is desirable to define a macro that expands into a compound
statement. Consider, for example, the following macro, that advances a
pointer (the argument @samp{p} says where to find it) across whitespace
@example
#define SKIP_SPACES(p, limit) \
-@{ register char *lim = (limit); \
- while (p != lim) @{ \
- if (*p++ != ' ') @{ \
+@{ char *lim = (limit); \
+ while (p < lim) @{ \
+ if (*p++ != ' ') @{ \
p--; break; @}@}@}
@end example
@noindent
Here backslash-newline is used to split the macro definition, which must
-be a single logical line, so that it resembles the way such C code would
+be a single logical line, so that it resembles the way such code would
be laid out if not part of a macro definition.
A call to this macro might be @samp{SKIP_SPACES (p, lim)}. Strictly
@example
#define SKIP_SPACES(p, limit) \
-do @{ register char *lim = (limit); \
- while (p != lim) @{ \
- if (*p++ != ' ') @{ \
- p--; break; @}@}@} \
+do @{ char *lim = (limit); \
+ while (p < lim) @{ \
+ if (*p++ != ' ') @{ \
+ p--; break; @}@}@} \
while (0)
@end example
@end example
@noindent
-which is one statement.
+which is one statement. The loop executes exactly once; most compilers
+generate no extra code for it.
-@node Side Effects, Self-Reference, Swallow Semicolon, Macro Pitfalls
-@subsubsection Duplication of Side Effects
+@node Duplication of Side Effects
+@subsection Duplication of Side Effects
@cindex side effects (in macro arguments)
@cindex unsafe macros
The best solution to this problem is to define @samp{min} in a way that
computes the value of @samp{foo (z)} only once. The C language offers
-no standard way to do this, but it can be done with GNU C extensions as
+no standard way to do this, but it can be done with GNU extensions as
follows:
@example
-#define min(X, Y) \
-(@{ typeof (X) __x = (X), __y = (Y); \
- (__x < __y) ? __x : __y; @})
+#define min(X, Y) \
+(@{ typeof (X) x_ = (X); \
+ typeof (Y) y_ = (Y); \
+ (x_ < y_) ? x_ : y_; @})
@end example
+The @samp{(@{ @dots{} @})} notation produces a compound statement that
+acts as an expression. Its value is the value of its last statement.
+This permits us to define local variables and assign each argument to
+one. The local variables have underscores after their names to reduce
+the risk of conflict with an identifier of wider scope (it is impossible
+to avoid this entirely). Now each argument is evaluated exactly once.
+
If you do not wish to use GNU C extensions, the only solution is to be
careful when @emph{using} the macro @samp{min}. For example, you can
calculate the value of @samp{foo (z)}, save it in a variable, and use
@noindent
(where we assume that @samp{foo} returns type @samp{int}).
-@node Self-Reference, Argument Prescan, Side Effects, Macro Pitfalls
-@subsubsection Self-Referential Macros
-
+@node Self-Referential Macros
+@subsection Self-Referential Macros
@cindex self-reference
-A @dfn{self-referential} macro is one whose name appears in its
-definition. A special feature of ISO Standard C is that the
-self-reference is not considered a macro call. It is passed into the
-preprocessor output unchanged.
-Let's consider an example:
+A @dfn{self-referential} macro is one whose name appears in its
+definition. Recall that all macro definitions are rescanned for more
+macros to replace. If the self-reference were considered a use of the
+macro, it would produce an infinitely large expansion. To prevent this,
+the self-reference is not considered a macro call. It is passed into
+the preprocessor output unchanged. Let's consider an example:
@example
#define foo (4 + foo)
Following the ordinary rules, each reference to @samp{foo} will expand
into @samp{(4 + foo)}; then this will be rescanned and will expand into
-@samp{(4 + (4 + foo))}; and so on until it causes a fatal error (memory
-full) in the preprocessor.
+@samp{(4 + (4 + foo))}; and so on until the computer runs out of memory.
-However, the special rule about self-reference cuts this process short
-after one step, at @samp{(4 + foo)}. Therefore, this macro definition
-has the possibly useful effect of causing the program to add 4 to the
-value of @samp{foo} wherever @samp{foo} is referred to.
+The self-reference rule cuts this process short after one step, at
+@samp{(4 + foo)}. Therefore, this macro definition has the possibly
+useful effect of causing the program to add 4 to the value of @samp{foo}
+wherever @samp{foo} is referred to.
In most cases, it is a bad idea to take advantage of this feature. A
person reading the program who sees that @samp{foo} is a variable will
identifier @samp{foo} in the program and think its value should be that
of the variable @samp{foo}, whereas in fact the value is four greater.
-The special rule for self-reference applies also to @dfn{indirect}
-self-reference. This is the case where a macro @var{x} expands to use a
-macro @samp{y}, and the expansion of @samp{y} refers to the macro
-@samp{x}. The resulting reference to @samp{x} comes indirectly from the
-expansion of @samp{x}, so it is a self-reference and is not further
-expanded. Thus, after
+One common, useful use of self-reference is to create a macro which
+expands to itself. If you write
+
+@example
+#define EPERM EPERM
+@end example
+
+@noindent
+then the macro @code{EPERM} expands to @samp{EPERM}. Effectively, it is
+left alone by the preprocessor whenever it's used in running text. You
+can tell that it's a macro with @samp{#ifdef}. You might do this if you
+want to define numeric constants with an @samp{enum}, but have
+@samp{#ifdef} be true for each constant.
+
+If a macro @code{x} expands to use a macro @code{y}, and the expansion of
+@code{y} refers to the macro @code{x}, that is an @dfn{indirect
+self-reference} of @code{x}. @code{x} is not expanded in this case
+either. Thus, if we have
@example
#define x (4 + y)
@end example
@noindent
-@samp{x} would expand into @samp{(4 + (2 * x))}. Clear?
+then @samp{x} and @samp{y} expand as follows:
+
+@example
+@group
+x @expansion{} (4 + y)
+ @expansion{} (4 + (2 * x))
-Suppose @samp{y} is used elsewhere, not from the definition of @samp{x}.
-Then the use of @samp{x} in the expansion of @samp{y} is not a
-self-reference because @samp{x} is not ``in progress''. So it does
-expand. However, the expansion of @samp{x} contains a reference to
-@samp{y}, and that is an indirect self-reference now because @samp{y} is
-``in progress''. The result is that @samp{y} expands to @samp{(2 * (4 +
-y))}.
+y @expansion{} (2 * x)
+ @expansion{} (2 * (4 + y))
+@end group
+@end example
-This behavior is specified by the ISO C standard, so you may need to
-understand it.
+@noindent
+Each macro is expanded when it appears in the definition of the other
+macro, but not when it indirectly appears in its own definition.
-@node Argument Prescan, Cascaded Macros, Self-Reference, Macro Pitfalls
-@subsubsection Separate Expansion of Macro Arguments
+@node Argument Prescan
+@subsection Argument Prescan
@cindex expansion of arguments
@cindex macro argument expansion
@cindex prescan of macro arguments
-We have explained that the expansion of a macro, including the substituted
-arguments, is re-scanned for macro calls to be expanded.
-
-What really happens is more subtle: first each argument is scanned
-separately for macro calls. Then the resulting tokens are substituted
-into the macro body to produce the macro expansion, and the macro
-expansion is scanned again for macros to expand.
-
+Macro arguments are completely macro-expanded before they are
+substituted into a macro body, unless they are stringified or pasted
+with other tokens. After substitution, the entire macro body, including
+the substituted arguments, is scanned again for macros to be expanded.
The result is that the arguments are scanned @emph{twice} to expand
macro calls in them.
You might expect the double scan to change the results when a
self-referential macro is used in an argument of another macro
-(@pxref{Self-Reference}): the self-referential macro would be expanded
-once in the first scan, and a second time in the second scan. However,
-this is not what happens. The self-references that do not expand in the
-first scan are marked so that they will not expand in the second scan
-either.
-
-The prescan is not done when an argument is stringified or concatenated.
-Thus,
-
-@example
-#define str(s) #s
-#define foo 4
-str (foo)
-@end example
+(@pxref{Self-Referential Macros}): the self-referential macro would be
+expanded once in the first scan, and a second time in the second scan.
+However, this is not what happens. The self-references that do not
+expand in the first scan are marked so that they will not expand in the
+second scan either.
-@noindent
-expands to @samp{"foo"}. Once more, prescan has been prevented from
-having any noticeable effect.
-
-More precisely, stringification and concatenation use the argument
-tokens as given without initially scanning for macros. The same
-argument would be used in expanded form if it is substituted elsewhere
-without stringification or concatenation.
-
-@example
-#define str(s) #s lose(s)
-#define foo 4
-str (foo)
-@end example
-
-expands to @samp{"foo" lose(4)}.
-
-You might now ask, ``Why mention the prescan, if it makes no difference?
+You might wonder, ``Why mention the prescan, if it makes no difference?
And why not skip it and make the preprocessor faster?'' The answer is
that the prescan does make a difference in three special cases:
@item
Nested calls to a macro.
-@item
-Macros that call other macros that stringify or concatenate.
-
-@item
-Macros whose expansions contain unshielded commas.
-@end itemize
-
We say that @dfn{nested} calls to a macro occur when a macro's argument
contains a call to that very macro. For example, if @samp{f} is a macro
that expects one argument, @samp{f (f (1))} is a nested pair of calls to
the expected result to happen. Without the prescan, @samp{f (1)} itself
would be substituted as an argument, and the inner use of @samp{f} would
appear during the main scan as an indirect self-reference and would not
-be expanded. Here, the prescan cancels an undesirable side effect (in
-the medical, not computational, sense of the term) of the special rule
-for self-referential macros.
+be expanded.
+
+@item
+Macros that call other macros that stringify or concatenate.
+
+If an argument is stringified or concatenated, the prescan does not
+occur. If you @emph{want} to expand a macro, then stringify or
+concatenate its expansion, you can do that by causing one macro to call
+another macro that does the stringification or concatenation. For
+instance, if you have
+
+@example
+#define AFTERX(x) X_ ## x
+#define XAFTERX(x) AFTERX(x)
+#define TABLESIZE 1024
+#define BUFSIZE TABLESIZE
+@end example
+
+then @samp{AFTERX(BUFSIZE)} expands to @samp{X_BUFSIZE}, and
+@samp{XAFTERX(BUFSIZE)} expands to @samp{X_1024}. (Not to
+@samp{X_TABLESIZE}. Prescan always does a complete expansion.)
+
+@item
+Macros used in arguments, whose expansions contain unshielded commas.
-Prescan causes trouble in certain other cases of nested macro calls.
-Here is an example:
+This can cause a macro expanded on the second scan to be called with the
+wrong number of arguments. Here is an example:
@example
#define foo a,b
#define bar(x) lose(x)
#define lose(x) (1 + (x))
-
-bar(foo)
@end example
-@noindent
We would like @samp{bar(foo)} to turn into @samp{(1 + (foo))}, which
would then turn into @samp{(1 + (a,b))}. Instead, @samp{bar(foo)}
expands into @samp{lose(a,b)}, and you get an error because @code{lose}
@example
#define foo (a,b)
+@exdent or
#define bar(x) lose((x))
@end example
-The problem is more serious when the operands of the macro are not
-expressions; for example, when they are statements. Then parentheses
-are unacceptable because they would make for invalid C code:
-
-@example
-#define foo @{ int a, b; @dots{} @}
-@end example
-
-@noindent
-In GNU C you can shield the commas using the @samp{(@{@dots{}@})}
-construct which turns a compound statement into an expression:
-
-@example
-#define foo (@{ int a, b; @dots{} @})
-@end example
-
-Or you can rewrite the macro definition to avoid such commas:
-
-@example
-#define foo @{ int a; int b; @dots{} @}
-@end example
-
-There is also one case where prescan is useful. It is possible to use
-prescan to expand an argument and then stringify it --- if you use two
-levels of macros. Let's add a new macro @samp{xstr} to the example
-shown above:
-
-@example
-#define xstr(s) str(s)
-#define str(s) #s
-#define foo 4
-xstr (foo)
-@end example
-
-This expands into @samp{"4"}, not @samp{"foo"}. The reason for the
-difference is that the argument of @samp{xstr} is expanded at prescan
-(because @samp{xstr} does not specify stringification or concatenation
-of the argument). The result of prescan then forms the argument for
-@samp{str}. @samp{str} uses its argument without prescan because it
-performs stringification; but it cannot prevent or undo the prescanning
-already done by @samp{xstr}.
-
-@node Cascaded Macros, Newlines in Args, Argument Prescan, Macro Pitfalls
-@subsubsection Cascaded Use of Macros
-
-@cindex cascaded macros
-@cindex macro body uses macro
-A @dfn{cascade} of macros is when one macro's body contains a reference
-to another macro. This is very common practice. For example,
-
-@example
-#define BUFSIZE 1020
-#define TABLESIZE BUFSIZE
-@end example
-
-This is not at all the same as defining @samp{TABLESIZE} to be
-@samp{1020}. The @samp{#define} for @samp{TABLESIZE} uses exactly the
-body you specify --- in this case, @samp{BUFSIZE} --- and does not check
-to see whether it too is the name of a macro.
-
-It's only when you @emph{use} @samp{TABLESIZE} that the result of its
-expansion is checked for more macro names.
-
-This makes a difference if you change the definition of @samp{BUFSIZE}
-at some point in the source file. @samp{TABLESIZE}, defined as shown,
-will always expand using the definition of @samp{BUFSIZE} that is
-currently in effect:
-
-@example
-#define BUFSIZE 1020
-#define TABLESIZE BUFSIZE
-#undef BUFSIZE
-#define BUFSIZE 37
-@end example
+The extra pair of parentheses prevents the comma in @code{foo}'s
+definition from being interpreted as an argument separator.
-@noindent
-Now @samp{TABLESIZE} expands (in two stages) to @samp{37}. (The
-@samp{#undef} is to prevent any warning about the nontrivial
-redefinition of @code{BUFSIZE}.)
+@end itemize
-@node Newlines in Args,, Cascaded Macros, Macro Pitfalls
-@subsection Newlines in Macro Arguments
+@node Newlines in Arguments
+@subsection Newlines in Arguments
@cindex newlines in macro arguments
The invocation of a function-like macro can extend over many logical
-lines. The ISO C standard requires that newlines within a macro
-invocation be treated as ordinary whitespace. This means that when the
-expansion of a function-like macro replaces its invocation, it appears
-on the same line as the macro name did. Thus line numbers emitted by
-the compiler or debugger refer to the line the invocation started on,
-which might be different to the line containing the argument causing the
-problem.
+lines. However, in the present implementation, the entire expansion
+comes out on one line. Thus line numbers emitted by the compiler or
+debugger refer to the line the invocation started on, which might be
+different to the line containing the argument causing the problem.
Here is an example illustrating this:
an error message citing line three --- the line of ignore_second_arg ---
even though the problematic code comes from line five.
-@node Conditionals, Assertions, Macros, Top
-@section Conditionals
+We consider this a bug, and intend to fix it in the near future.
+@node Conditionals
+@chapter Conditionals
@cindex conditionals
-In a macro processor, a @dfn{conditional} is a directive that allows a
-part of the program to be ignored during compilation, on some
-conditions. In the C preprocessor, a conditional can test either an
-arithmetic expression or whether a name is defined as a macro.
+
+A @dfn{conditional} is a directive that instructs the preprocessor to
+select whether or not to include a chunk of code in the final token
+stream passed to the compiler. Preprocessor conditionals can test
+arithmetic expressions, or whether a name is defined as a macro, or both
+simultaneously using the special @samp{defined} operator.
A conditional in the C preprocessor resembles in some ways an @samp{if}
statement in C, but it is important to understand the difference between
code to be included in the program depending on the situation at the
time of compilation.
+However, the distinction is becoming less clear. Modern compilers often
+do test @samp{if} statements when a program is compiled, if their
+conditions are known not to vary at run time, and eliminate code which
+can never be executed. If you can count on your compiler to do this,
+you may find that your program is more readable if you use @samp{if}
+statements with constant conditions (perhaps determined by macros). Of
+course, you can only use this to exclude code, not type definitions or
+other preprocessing directives, and you can only do it if the code
+remains syntactically valid when it is not to be used.
+
+GNU C version 3 eliminates this kind of never-executed code even when
+not optimizing. Older versions did it only when optimizing.
+
@menu
-* Uses: Conditional Uses. What conditionals are for.
-* Syntax: Conditional Syntax. How conditionals are written.
-* Deletion: Deleted Code. Making code into a comment.
-* Macros: Conditionals-Macros. Why conditionals are used with macros.
-* Errors: #error Directive. Detecting inconsistent compilation parameters.
+* Conditional Uses::
+* Conditional Syntax::
+* Deleted Code::
@end menu
@node Conditional Uses
-@subsection Why Conditionals are Used
+@section Conditional Uses
-Generally there are three kinds of reason to use a conditional.
+There are three general reasons to use a conditional.
@itemize @bullet
@item
A program may need to use different code depending on the machine or
operating system it is to run on. In some cases the code for one
operating system may be erroneous on another operating system; for
-example, it might refer to library routines that do not exist on the
-other system. When this happens, it is not enough to avoid executing
-the invalid code: merely having it in the program makes it impossible to
-link the program and run it. With a preprocessing conditional, the
-offending code can be effectively excised from the program when it is
-not valid.
+example, it might refer to data types or constants that do not exist on
+the other system. When this happens, it is not enough to avoid
+executing the invalid code. Its mere presence will cause the compiler
+to reject the program. With a preprocessing conditional, the offending
+code can be effectively excised from the program when it is not valid.
@item
You may want to be able to compile the same source file into two
-different programs. Sometimes the difference between the programs is
-that one makes frequent time-consuming consistency checks on its
-intermediate data, or prints the values of those data for debugging,
-while the other does not.
+different programs. One version might make frequent time-consuming
+consistency checks on its intermediate data, or print the values of
+those data for debugging, and the other not.
@item
-A conditional whose condition is always false is a good way to exclude
-code from the program but keep it as a sort of comment for future
-reference.
+A conditional whose condition is always false is one way to exclude code
+from the program but keep it as a sort of comment for future reference.
@end itemize
-Most simple programs that are intended to run on only one machine will
-not need to use preprocessing conditionals.
+Simple programs that do not need system-specific logic or complex
+debugging hooks generally will not need to use preprocessing
+conditionals.
@node Conditional Syntax
-@subsection Syntax of Conditionals
+@section Conditional Syntax
@findex #if
A conditional in the C preprocessor begins with a @dfn{conditional
directive}: @samp{#if}, @samp{#ifdef} or @samp{#ifndef}.
-@xref{Conditionals-Macros}, for information on @samp{#ifdef} and
-@samp{#ifndef}; only @samp{#if} is explained here.
@menu
-* If: #if Directive. Basic conditionals using @samp{#if} and @samp{#endif}.
-* Else: #else Directive. Including some text if the condition fails.
-* Elif: #elif Directive. Testing several alternative possibilities.
+* Ifdef::
+* If::
+* Defined::
+* Else::
+* Elif::
@end menu
-@node #if Directive
-@subsubsection The @samp{#if} Directive
+@node Ifdef
+@subsection Ifdef
+@findex #ifdef
+@findex #endif
-The @samp{#if} directive in its simplest form consists of
+The simplest sort of conditional is
@example
-#if @var{expression}
+@group
+#ifdef @var{MACRO}
+
@var{controlled text}
-#endif /* @var{expression} */
+
+#endif /* @var{MACRO} */
+@end group
@end example
+@cindex conditional group
+This block is called a @dfn{conditional group}. @var{controlled text}
+will be included in the output of the preprocessor if and only if
+@var{MACRO} is defined. We say that the conditional @dfn{succeeds} if
+@var{MACRO} is defined, @dfn{fails} if it is not.
+
+The @var{controlled text} inside of a conditional can include
+preprocessing directives. They are executed only if the conditional
+succeeds. You can nest conditional groups inside other conditional
+groups, but they must be completely nested. In other words,
+@samp{#endif} always matches the nearest @samp{#ifdef} (or
+@samp{#ifndef}, or @samp{#if}). Also, you cannot start a conditional
+group in one file and end it in another.
+
+Even if a conditional fails, the @var{controlled text} inside it is
+still run through initial transformations and tokenization. Therefore,
+it must all be lexically valid C. Normally the only way this matters is
+that all comments and string literals inside a failing conditional group
+must still be properly ended.
+
The comment following the @samp{#endif} is not required, but it is a
-good practice because it helps people match the @samp{#endif} to the
-corresponding @samp{#if}. Such comments should always be used, except
-in short conditionals that are not nested. In fact, you can put
-anything at all after the @samp{#endif} and it will be ignored by the
-GNU C preprocessor, but only comments are acceptable in ISO Standard C@.
+good practice if there is a lot of @var{controlled text}, because it
+helps people match the @samp{#endif} to the corresponding @samp{#ifdef}.
+Older programs sometimes put @var{MACRO} directly after the
+@samp{#endif} without enclosing it in a comment. This is invalid code
+according to the C standard. GNU CPP accepts it with a warning. It
+never affects which @samp{#ifndef} the @samp{#endif} matches.
+
+@findex #ifndef
+Sometimes you wish to use some code if a macro is @emph{not} defined.
+You can do this by writing @samp{#ifndef} instead of @samp{#ifdef}.
+One common use of @samp{#ifndef} is to include code only the first
+time a header file is included. @xref{Once-Only Headers}.
+
+Macro definitions can vary between compilations for several reasons.
+Here are some samples.
+
+@itemize @bullet
+@item
+Some macros are predefined on each kind of machine
+(@pxref{System-specific Predefined Macros}). This allows you to provide
+code specially tuned for a particular machine.
+
+@item
+System header files define more macros, associated with the features
+they implement. You can test these macros with conditionals to avoid
+using a system feature on a machine where it is not implemented.
+
+@item
+Macros can be defined or undefined with the @option{-D} and @option{-U}
+command line options when you compile the program. You can arrange to
+compile the same source file into two different programs by choosing a
+macro name to specify which program you want, writing conditionals to
+test whether or how this macro is defined, and then controlling the
+state of the macro with command line options, perhaps set in the
+Makefile. @xref{Invocation}.
+
+@item
+Your program might have a special header file (often called
+@file{config.h}) that is adjusted when the program is compiled. It can
+define or not define macros depending on the features of the system and
+the desired capabilities of the program. The adjustment can be
+automated by a tool such as @docref{autoconf}, or done by hand.
+@end itemize
+
+@node If
+@subsection If
+
+The @samp{#if} directive allows you to test the value of an arithmetic
+expression, rather than the mere existence of one macro. Its syntax is
+
+@example
+@group
+#if @var{expression}
+
+@var{controlled text}
+
+#endif /* @var{expression} */
+@end group
+@end example
@var{expression} is a C expression of integer type, subject to stringent
restrictions. It may contain
@itemize @bullet
@item
-Integer constants, which are all regarded as @code{long} or
-@code{unsigned long}.
+Integer constants.
@item
-Character constants, which are interpreted according to the character
-set and conventions of the machine and operating system on which the
-preprocessor is running. The GNU C preprocessor uses the C data type
-@samp{char} for these character constants; therefore, whether some
-character codes are negative is determined by the C compiler used to
-compile the preprocessor. If it treats @samp{char} as signed, then
-character codes large enough to set the sign bit will be considered
-negative; otherwise, no character code is considered negative.
+Character constants, which are interpreted as they would be in normal
+code.
@item
Arithmetic operators for addition, subtraction, multiplication,
short-circuiting rules of standard C.
@item
-Identifiers that are not macros, which are all treated as zero(!).
+Macros. All macros in the expression are expanded before actual
+computation of the expression's value begins.
+
+@item
+Uses of the @samp{defined} operator, which lets you check whether macros
+are defined in the middle of an @samp{#if}.
@item
-Macro calls. All macro calls in the expression are expanded before
-actual computation of the expression's value begins.
+Identifiers that are not macros, which are all considered to be the
+number zero. This allows you to write @samp{@w{#if MACRO}} instead of
+@samp{@w{#ifdef MACRO}}, if you know that MACRO, when defined, will
+always have a nonzero value. Function-like macros used without their
+function call parentheses are also treated as zero.
+
+In some contexts this shortcut is undesirable. The @option{-Wundef}
+option causes GCC to warn whenever it encounters an identifier which is
+not a macro in an @samp{#if}.
@end itemize
-Note that @samp{sizeof} operators and @code{enum}-type values are not
-allowed. @code{enum}-type values, like all other identifiers that are
-not taken as macro calls and expanded, are treated as zero.
+The preprocessor does not know anything about types in the language.
+Therefore, @code{sizeof} operators are not recognized in @samp{#if}, and
+neither are @code{enum} constants. They will be taken as identifiers
+which are not macros, and replaced by zero. In the case of
+@code{sizeof}, this is likely to cause the expression to be invalid.
-The @var{controlled text} inside of a conditional can include
-preprocessing directives. Then the directives inside the conditional
-are obeyed only if that branch of the conditional succeeds. The text
-can also contain other conditional groups. However, the @samp{#if} and
-@samp{#endif} directives must balance.
+The preprocessor calculates the value of @var{expression}. It carries
+out all calculations in the widest integer type known to the compiler;
+on most machines supported by GCC this is 64 bits. This is not the same
+rule as the compiler uses to calculate the value of a constant
+expression, and may give different results in some cases. If the value
+comes out to be nonzero, the @samp{#if} succeeds and the @var{controlled
+text} is included; otherwise it is skipped.
+
+If @var{expression} is not correctly formed, GCC issues an error and
+treats the conditional as having failed.
+
+@node Defined
+@subsection Defined
+
+@cindex @code{defined}
+The special operator @samp{defined} is used in @samp{#if} and
+@samp{#elif} expressions to test whether a certain name is defined as a
+macro. @samp{defined @var{name}} and @samp{defined (@var{name})} are
+both expressions whose value is 1 if @var{name} is defined as a macro at
+the current point in the program, and 0 otherwise. Thus, @samp{@w{#if
+defined MACRO}} is precisely equivalent to @samp{@w{#ifdef MACRO}}.
+
+@samp{defined} is useful when you wish to test more than one macro for
+existence at once. For example,
+
+@example
+#if defined (__vax__) || defined (__ns16000__)
+@end example
+
+@noindent
+would succeed if either of the names @samp{__vax__} or
+@samp{__ns16000__} is defined as a macro.
+
+Conditionals written like this:
+
+@example
+#if defined BUFSIZE && BUFSIZE >= 1024
+@end example
+
+@noindent
+can generally be simplified to just @samp{@w{#if BUFSIZE >= 1024}},
+since if @samp{BUFSIZE} is not defined, it will be interpreted as having
+the value zero.
+
+If the @samp{defined} operator appears as a result of a macro expansion,
+the C standard says the behavior is undefined. GNU cpp treats it as a
+genuine @samp{defined} operator and evaluates it normally. It will warn
+wherever your code uses this feature if you use the command-line option
+@option{-pedantic}, since other compilers may handle it differently.
-@node #else Directive
-@subsubsection The @samp{#else} Directive
+@node Else
+@subsection Else
@findex #else
The @samp{#else} directive can be added to a conditional to provide
-alternative text to be used if the condition is false. This is what
-it looks like:
+alternative text to be used if the condition fails. This is what it
+looks like:
@example
#if @var{expression}
#endif /* Not @var{expression} */
@end example
-If @var{expression} is nonzero, and thus the @var{text-if-true} is
-active, then @samp{#else} acts like a failing conditional and the
-@var{text-if-false} is ignored. Conversely, if the @samp{#if}
-conditional fails, the @var{text-if-false} is considered included.
+If @var{expression} is nonzero, the @var{text-if-true} is included and
+the @var{text-if-false} is skipped. If @var{expression} is zero, the
+opposite happens.
-@node #elif Directive
-@subsubsection The @samp{#elif} Directive
+You can use @samp{#else} with @samp{#ifdef} and @samp{#ifndef}, too.
+
+@node Elif
+@subsection Elif
@findex #elif
One common case of nested conditionals is used to check for more than two
@end example
@samp{#elif} stands for ``else if''. Like @samp{#else}, it goes in the
-middle of a @samp{#if}-@samp{#endif} pair and subdivides it; it does not
-require a matching @samp{#endif} of its own. Like @samp{#if}, the
-@samp{#elif} directive includes an expression to be tested.
-
-The text following the @samp{#elif} is processed only if the original
-@samp{#if}-condition failed and the @samp{#elif} condition succeeds.
-More than one @samp{#elif} can go in the same @samp{#if}-@samp{#endif}
-group. Then the text after each @samp{#elif} is processed only if the
-@samp{#elif} condition succeeds after the original @samp{#if} and any
-previous @samp{#elif} directives within it have failed. @samp{#else} is
-equivalent to @samp{#elif 1}, and @samp{#else} is allowed after any
-number of @samp{#elif} directives, but @samp{#elif} may not follow
-@samp{#else}.
+middle of a conditional group and subdivides it; it does not require a
+matching @samp{#endif} of its own. Like @samp{#if}, the @samp{#elif}
+directive includes an expression to be tested. The text following the
+@samp{#elif} is processed only if the original @samp{#if}-condition
+failed and the @samp{#elif} condition succeeds.
+
+More than one @samp{#elif} can go in the same conditional group. Then
+the text after each @samp{#elif} is processed only if the @samp{#elif}
+condition succeeds after the original @samp{#if} and all previous
+@samp{#elif} directives within it have failed.
+
+@samp{#else} is allowed after any number of @samp{#elif} directives, but
+@samp{#elif} may not follow @samp{#else}.
@node Deleted Code
-@subsection Keeping Deleted Code for Future Reference
+@section Deleted Code
@cindex commenting out code
If you replace or delete a part of the program but want to keep the old
-code around as a comment for future reference, the easy way to do this
-is to put @samp{#if 0} before it and @samp{#endif} after it. This is
-better than using comment delimiters @samp{/*} and @samp{*/} since those
-won't work if the code already contains comments (C comments do not
-nest).
-
-This works even if the code being turned off contains conditionals, but
-they must be entire conditionals (balanced @samp{#if} and @samp{#endif}).
-
-Conversely, do not use @samp{#if 0} for comments which are not C code.
-Use the comment delimiters @samp{/*} and @samp{*/} instead. The
-interior of @samp{#if 0} must consist of complete tokens; in particular,
-single-quote characters must balance. Comments often contain unbalanced
-single-quote characters (known in English as apostrophes). These
-confuse @samp{#if 0}. They do not confuse @samp{/*}.
-
-@node Conditionals-Macros
-@subsection Conditionals and Macros
-
-Conditionals are useful in connection with macros or assertions, because
-those are the only ways that an expression's value can vary from one
-compilation to another. A @samp{#if} directive whose expression uses no
-macros or assertions is equivalent to @samp{#if 1} or @samp{#if 0}; you
-might as well determine which one, by computing the value of the
-expression yourself, and then simplify the program.
-
-For example, here is a conditional that tests the expression
-@samp{BUFSIZE == 1020}, where @samp{BUFSIZE} must be a macro.
-
-@example
-#if BUFSIZE == 1020
- printf ("Large buffers!\n");
-#endif /* BUFSIZE is large */
-@end example
-
-(Programmers often wish they could test the size of a variable or data
-type in @samp{#if}, but this does not work. The preprocessor does not
-understand @code{sizeof}, or typedef names, or even the type keywords
-such as @code{int}.)
-
-@findex defined
-The special operator @samp{defined} is used in @samp{#if} and
-@samp{#elif} expressions to test whether a certain name is defined as a
-macro. Either @samp{defined @var{name}} or @samp{defined (@var{name})}
-is an expression whose value is 1 if @var{name} is defined as macro at
-the current point in the program, and 0 otherwise. To the
-@samp{defined} operator it makes no difference what the definition of
-the macro is; all that matters is whether there is a definition. Thus,
-for example,@refill
-
-@example
-#if defined (vax) || defined (ns16000)
-@end example
-
-@noindent
-would succeed if either of the names @samp{vax} and @samp{ns16000} is
-defined as a macro. You can test the same condition using assertions
-(@pxref{Assertions}), like this:
-
-@example
-#if #cpu (vax) || #cpu (ns16000)
-@end example
-
-If a macro is defined and later undefined with @samp{#undef}, subsequent
-use of the @samp{defined} operator returns 0, because the name is no
-longer defined. If the macro is defined again with another
-@samp{#define}, @samp{defined} will recommence returning 1.
-
-If the @samp{defined} operator appears as a result of a macro expansion,
-the C standard says the behavior is undefined. GNU cpp treats it as a
-genuine @samp{defined} operator and evaluates it normally. It will warn
-wherever your code uses this feature if you use the command-line option
-@samp{-pedantic}, since other compilers may handle it differently.
-
-@findex #ifdef
-@findex #ifndef
-Conditionals that test whether a single macro is defined are very common,
-so there are two special short conditional directives for this case.
-
-@table @code
-@item #ifdef @var{name}
-is equivalent to @samp{#if defined (@var{name})}.
-
-@item #ifndef @var{name}
-is equivalent to @samp{#if ! defined (@var{name})}.
-@end table
-
-Macro definitions can vary between compilations for several reasons.
-
-@itemize @bullet
-@item
-Some macros are predefined on each kind of machine. For example, on a
-Vax, the name @samp{vax} is a predefined macro. On other machines, it
-would not be defined.
-
-@item
-Many more macros are defined by system header files. Different systems
-and machines define different macros, or give them different values. It
-is useful to test these macros with conditionals to avoid using a system
-feature on a machine where it is not implemented.
-
-@item
-Macros are a common way of allowing users to customize a program for
-different machines or applications. For example, the macro
-@samp{BUFSIZE} might be defined in a configuration file for your program
-that is included as a header file in each source file. You would use
-@samp{BUFSIZE} in a preprocessing conditional in order to generate
-different code depending on the chosen configuration.
-
-@item
-Macros can be defined or undefined with @samp{-D} and @samp{-U} command
-options when you compile the program. You can arrange to compile the
-same source file into two different programs by choosing a macro name to
-specify which program you want, writing conditionals to test whether or
-how this macro is defined, and then controlling the state of the macro
-with compiler command options. @xref{Invocation}.
-@end itemize
-
-@ifinfo
-Assertions are usually predefined, but can be defined with preprocessor
-directives or command-line options.
-@end ifinfo
-
-@node #error Directive
-@subsection The @samp{#error} and @samp{#warning} Directives
+code around for future reference, you often cannot simply comment it
+out. Block comments do not nest, so the first comment inside the old
+code will end the commenting-out. The probable result is a flood of
+syntax errors.
+
+One way to avoid this problem is to use an always-false conditional
+instead. For instance, put @samp{#if 0} before the deleted code and
+@samp{#endif} after it. This This works even if the code being turned
+off contains conditionals, but they must be entire conditionals
+(balanced @samp{#if} and @samp{#endif}).
+
+Some people use @samp{#ifdef notdef} instead. This is risky, because
+@samp{notdef} might be accidentally defined as a macro, and then the
+conditional would succeed. @samp{#if 0} can be counted on to fail.
+
+Do not use @samp{#if 0} for comments which are not C code. Use a real
+comment, instead. The interior of @samp{#if 0} must consist of complete
+tokens; in particular, single-quote characters must balance. Comments
+often contain unbalanced single-quote characters (known in English as
+apostrophes). These confuse @samp{#if 0}. They don't confuse
+@samp{/*}.
+
+@node Diagnostics
+@chapter Diagnostics
+@cindex diagnostic
+@cindex reporting errors
+@cindex reporting warnings
@findex #error
The directive @samp{#error} causes the preprocessor to report a fatal
error. The tokens forming the rest of the line following @samp{#error}
-are used as the error message, and not macro-expanded. Internal
-whitespace sequences are each replaced with a single space. The line
-must consist of complete tokens.
+are used as the error message.
You would use @samp{#error} inside of a conditional that detects a
combination of parameters which you know the program does not properly
support. For example, if you know that the program will not run
properly on a Vax, you might write
-@smallexample
+@example
@group
#ifdef __vax__
#error "Won't work on Vaxen. See comments at get_last_object."
#endif
@end group
-@end smallexample
-
-@noindent
-@xref{Nonstandard Predefined}, for why this works.
+@end example
If you have several configuration parameters that must be set up by
the installation in a consistent way, you can use conditionals to detect
an inconsistency and report it with @samp{#error}. For example,
-@smallexample
-#if HASH_TABLE_SIZE % 2 == 0 || HASH_TABLE_SIZE % 3 == 0 \
- || HASH_TABLE_SIZE % 5 == 0
-#error HASH_TABLE_SIZE should not be divisible by a small prime
+@example
+#if !defined(UNALIGNED_INT_ASM_OP) && defined(DWARF2_DEBUGGING_INFO)
+#error "DWARF2_DEBUGGING_INFO requires UNALIGNED_INT_ASM_OP."
#endif
-@end smallexample
+@end example
@findex #warning
-The directive @samp{#warning} is like the directive @samp{#error}, but
-causes the preprocessor to issue a warning and continue preprocessing.
-The tokens following @samp{#warning} are used as the warning message,
-and not macro-expanded.
+The directive @samp{#warning} is like @samp{#error}, but causes the
+preprocessor to issue a warning and continue preprocessing. The tokens
+following @samp{#warning} are used as the warning message.
You might use @samp{#warning} in obsolete header files, with a message
directing the user to the header file which should be used instead.
-@node Assertions, Line Control, Conditionals, Top
-@section Assertions
-@cindex assertions
-@dfn{Assertions} are a more systematic alternative to macros in writing
-conditionals to test what sort of computer or system the compiled
-program will run on. Assertions are usually predefined, but you can
-define them with preprocessing directives or command-line options.
+Neither @samp{#error} nor @samp{#warning} macro-expands its argument.
+Internal whitespace sequences are each replaced with a single space.
+The line must consist of complete tokens. It is wisest to make the
+argument of these directives be a single string constant; this avoids
+problems with apostrophes and the like.
-@cindex predicates
-The macros traditionally used to describe the type of target are not
-classified in any way according to which question they answer; they may
-indicate a hardware architecture, a particular hardware model, an
-operating system, a particular version of an operating system, or
-specific configuration options. These are jumbled together in a single
-namespace. In contrast, each assertion consists of a named question and
-an answer. The question is usually called the @dfn{predicate}. An
-assertion looks like this:
+@node Line Control
+@chapter Line Control
+@cindex line control
-@example
-#@var{predicate} (@var{answer})
-@end example
+The C preprocessor informs the C compiler of the location in your source
+code where each token came from. Presently, this is just the file name
+and line number. All the tokens resulting from macro expansion are
+reported as having appeared on the line of the source file where the
+outermost macro was used. We intend to be more accurate in the future.
-@noindent
-You must use a properly formed identifier for @var{predicate}. The
-value of @var{answer} can be any sequence of words; all characters are
-significant except for leading and trailing whitespace, and differences
-in internal whitespace sequences are ignored. (This is similar to the
-rules governing macro redefinition.) Thus, @samp{x + y} is different
-from @samp{x+y} but equivalent to @samp{ x + y }. @samp{)} is not
-allowed in an answer.
+If you write a program which generates source code, such as the
+@code{bison} parser generator, you may want to adjust the preprocessor's
+notion of the current file name and line number by hand. Parts of the
+output from @code{bison} are generated from scratch, other parts come
+from a standard parser file. The rest are copied verbatim from
+@code{bison}'s input. You would like compiler error messages and
+symbolic debuggers to be able to refer to @code{bison}'s input file.
-@cindex testing predicates
-Here is a conditional to test whether the answer @var{answer} is asserted
-for the predicate @var{predicate}:
+@findex #line
+@code{bison} or any such program can arrange this by writing
+@samp{#line} directives into the output file. @samp{#line} is a
+directive that specifies the original line number and source file name
+for subsequent input in the current preprocessor input file.
+@samp{#line} has four variants:
-@example
-#if #@var{predicate} (@var{answer})
-@end example
+@table @code
+@item #line @var{linenum}
+@var{linenum} is a decimal integer constant. It specifies the line
+number which should be reported for the following line of input.
+Subsequent lines are counted from @var{linenum}.
-@noindent
-There may be more than one answer asserted for a given predicate. If
-you omit the answer, you can test whether @emph{any} answer is asserted
-for @var{predicate}:
+@item #line @var{linenum} @var{filename}
+@var{linenum} is the same as for the first form, and has the same
+effect. In addition, @var{filename} is a string constant. The
+following line and all subsequent lines are reported to come from the
+file it specifies, until something else happens to change that.
-@example
-#if #@var{predicate}
-@end example
+@item #line @var{linenum} @var{filename} @var{flags@dots{}}
+This form is a GCC extension. @var{linenum} and @var{filename} are the
+same as the second form. The @var{flags} are small positive integers,
+which have the same meaning as the flags which can appear at the end of a
+linemarker in the preprocessor's output. @xref{Preprocessor Output}.
+
+@item #line @var{anything else}
+@var{anything else} is checked for macro calls, which are expanded.
+The result should match one of the above three forms.
+@end table
-@findex #system
-@findex #machine
-@findex #cpu
-Most of the time, the assertions you test will be predefined assertions.
-GNU C provides three predefined predicates: @code{system}, @code{cpu},
-and @code{machine}. @code{system} is for assertions about the type of
-software, @code{cpu} describes the type of computer architecture, and
-@code{machine} gives more information about the computer. For example,
-on a GNU system, the following assertions would be true:
+@samp{#line} directives alter the results of the @code{__FILE__} and
+@code{__LINE__} predefined macros from that point on. @xref{Standard
+Predefined Macros}. They do not have any effect on @samp{#include}'s
+idea of the directory containing the current file.
+
+@node Pragmas
+@chapter Pragmas
+
+The @samp{#pragma} directive is the method specified by the C standard
+for providing additional information to the compiler, beyond what is
+conveyed in the language itself. Three forms of this directive
+(commonly known as @dfn{pragmas}) are specified by the 1999 C standard.
+A C compiler is free to attach any meaning it likes to other pragmas.
+
+GCC has historically preferred to use extensions to the syntax of the
+language, such as @samp{__attribute__}, for this purpose. However, GCC
+does define a few pragmas of its own. These mostly have effects on the
+entire translation unit or source file.
+
+In GCC version 3, all GNU-defined, supported pragmas have been given a
+@samp{GCC} prefix. This is in line with the @samp{STDC} prefix on all
+pragmas defined by C99. For backward compatibility, pragmas which were
+recognized by previous versions are still recognized without the
+@samp{GCC} prefix, but that usage is deprecated. Some older pragmas are
+deprecated in their entirety. They are not recognized with the
+@samp{GCC} prefix. @xref{Obsolete Features}.
+
+@cindex @code{_Pragma}
+C99 introduces the @samp{_Pragma} operator. This feature addresses a
+major problem with @samp{#pragma}: being a directive, it cannot be
+produced as the result of macro expansion. @samp{_Pragma} is an
+operator, much like @samp{sizeof} or @samp{defined}, and can be embedded
+in a macro.
+
+The syntax is @code{_Pragma (string-literal)}, where
+@samp{string-literal} can be either a normal or wide-character string
+literal. It is destringized, by replacing all @samp{\\} with a single
+@samp{\} and all @samp{\"} with a @samp{"}. The result is then
+processed as if it had appeared as the right hand side of a
+@samp{#pragma} directive. For example,
@example
-#system (gnu)
-#system (mach)
-#system (mach 3)
-#system (mach 3.@var{subversion})
-#system (hurd)
-#system (hurd @var{version})
+_Pragma ("GCC dependency \"parse.y\"")
@end example
@noindent
-and perhaps others. The alternatives with
-more or less version information let you ask more or less detailed
-questions about the type of system software.
-
-On a Unix system, you would find @code{#system (unix)} and perhaps one of:
-@code{#system (aix)}, @code{#system (bsd)}, @code{#system (hpux)},
-@code{#system (lynx)}, @code{#system (mach)}, @code{#system (posix)},
-@code{#system (svr3)}, @code{#system (svr4)}, or @code{#system (xpg4)}
-with possible version numbers following.
-
-Other values for @code{system} are @code{#system (mvs)}
-and @code{#system (vms)}.
-
-@strong{Portability note:} Many Unix C compilers provide only one answer
-for the @code{system} assertion: @code{#system (unix)}, if they support
-assertions at all. This is less than useful.
-
-An assertion with a multi-word answer is completely different from several
-assertions with individual single-word answers. For example, the presence
-of @code{system (mach 3.0)} does not mean that @code{system (3.0)} is true.
-It also does not directly imply @code{system (mach)}, but in GNU C, that
-last will normally be asserted as well.
-
-The current list of possible assertion values for @code{cpu} is:
-@code{#cpu (a29k)}, @code{#cpu (alpha)}, @code{#cpu (arm)}, @code{#cpu
-(clipper)}, @code{#cpu (convex)}, @code{#cpu (elxsi)}, @code{#cpu
-(tron)}, @code{#cpu (h8300)}, @code{#cpu (i370)}, @code{#cpu (i386)},
-@code{#cpu (i860)}, @code{#cpu (i960)}, @code{#cpu (m68k)}, @code{#cpu
-(m88k)}, @code{#cpu (mips)}, @code{#cpu (ns32k)}, @code{#cpu (hppa)},
-@code{#cpu (pyr)}, @code{#cpu (ibm032)}, @code{#cpu (rs6000)},
-@code{#cpu (sh)}, @code{#cpu (sparc)}, @code{#cpu (spur)}, @code{#cpu
-(tahoe)}, @code{#cpu (vax)}, @code{#cpu (we32000)}.
-
-@findex #assert
-You can create assertions within a C program using @samp{#assert}, like
-this:
+has the same effect as @samp{#pragma GCC dependency "parse.y"}. The
+same effect could be achieved using macros, for example
@example
-#assert @var{predicate} (@var{answer})
+#define DO_PRAGMA(x) _Pragma (#x)
+DO_PRAGMA (GCC dependency "parse.y")
@end example
-@noindent
-(Note the absence of a @samp{#} before @var{predicate}.)
+The standard is unclear on where a @samp{_Pragma} operator can appear.
+The preprocessor accepts it even within a preprocessing conditional
+directive like @samp{#if}. To be safe, you are probably best keeping it
+out of directives other than @samp{#define}, and putting it on a line of
+its own.
-@cindex unassert
-@cindex assertions, undoing
-@cindex retracting assertions
-@findex #unassert
-Each time you do this, you assert a new true answer for @var{predicate}.
-Asserting one answer does not invalidate previously asserted answers;
-they all remain true. The only way to remove an answer is with
-@samp{#unassert}. @samp{#unassert} has the same syntax as
-@samp{#assert}. You can also remove all answers to a @var{predicate}
-like this:
+This manual documents the pragmas which are meaningful to the
+preprocessor itself. Other pragmas are meaningful to the C or C++
+compilers. They are documented in the GCC manual.
+
+@ftable @samp
+@item #pragma GCC dependency
+@samp{#pragma GCC dependency} allows you to check the relative dates of
+the current file and another file. If the other file is more recent than
+the current file, a warning is issued. This is useful if the current
+file is derived from the other file, and should be regenerated. The
+other file is searched for using the normal include search path.
+Optional trailing text can be used to give more information in the
+warning message.
@example
-#unassert @var{predicate}
+#pragma GCC dependency "parse.y"
+#pragma GCC dependency "/usr/include/time.h" rerun fixincludes
@end example
-You can also add or cancel assertions using command options
-when you run @code{gcc} or @code{cpp}. @xref{Invocation}.
-
-@node Line Control, Other Directives, Assertions, Top
-@section Combining Source Files
+@item #pragma GCC poison
+Sometimes, there is an identifier that you want to remove completely
+from your program, and make sure that it never creeps back in. To
+enforce this, you can @dfn{poison} the identifier with this pragma.
+@samp{#pragma GCC poison} is followed by a list of identifiers to
+poison. If any of those identifiers appears anywhere in the source
+after the directive, it is a hard error. For example,
-@cindex line control
-One of the jobs of the C preprocessor is to inform the C compiler of where
-each line of C code came from: which source file and which line number.
-
-C code can come from multiple source files if you use @samp{#include};
-both @samp{#include} and the use of conditionals and macros can cause
-the line number of a line in the preprocessor output to be different
-from the line's number in the original source file. You will appreciate
-the value of making both the C compiler (in error messages) and symbolic
-debuggers such as GDB use the line numbers in your source file.
-
-The C preprocessor builds on this feature by offering a directive by
-which you can control the feature explicitly. This is useful when a
-file for input to the C preprocessor is the output from another program
-such as the @code{bison} parser generator, which operates on another
-file that is the true source file. Parts of the output from
-@code{bison} are generated from scratch, other parts come from a
-standard parser file. The rest are copied nearly verbatim from the
-source file, but their line numbers in the @code{bison} output are not
-the same as their original line numbers. Naturally you would like
-compiler error messages and symbolic debuggers to know the original
-source file and line number of each line in the @code{bison} input.
+@example
+#pragma GCC poison printf sprintf fprintf
+sprintf(some_string, "hello");
+@end example
-@findex #line
-@code{bison} arranges this by writing @samp{#line} directives into the output
-file. @samp{#line} is a directive that specifies the original line number
-and source file name for subsequent input in the current preprocessor input
-file. @samp{#line} has three variants:
+@noindent
+will produce an error.
-@table @code
-@item #line @var{linenum}
-Here @var{linenum} is a decimal integer constant. This specifies that
-the line number of the following line of input, in its original source file,
-was @var{linenum}.
+If a poisoned identifier appears as part of the expansion of a macro
+which was defined before the identifier was poisoned, it will @emph{not}
+cause an error. This lets you poison an identifier without worrying
+about system headers defining macros that use it.
-@item #line @var{linenum} @var{filename}
-Here @var{linenum} is a decimal integer constant and @var{filename} is a
-string constant. This specifies that the following line of input came
-originally from source file @var{filename} and its line number there was
-@var{linenum}. Keep in mind that @var{filename} is not just a file
-name; it is surrounded by double-quote characters so that it looks like
-a string constant.
+For example,
-@item #line @var{anything else}
-@var{anything else} is checked for macro calls, which are expanded.
-The result should be a decimal integer constant followed optionally
-by a string constant, as described above.
-@end table
+@example
+#define strrchr rindex
+#pragma GCC poison rindex
+strrchr(some_string, 'h');
+@end example
-@samp{#line} directives alter the results of the @samp{__FILE__} and
-@samp{__LINE__} predefined macros from that point on. @xref{Standard
-Predefined}.
-
-The output of the preprocessor (which is the input for the rest of the
-compiler) contains directives that look much like @samp{#line}
-directives. They start with just @samp{#} instead of @samp{#line}, but
-this is followed by a line number and file name as in @samp{#line}.
-@xref{Output}.
-
-@node Other Directives, Output, Line Control, Top
-@section Miscellaneous Preprocessing Directives
-
-This section describes some additional, rarely used, preprocessing
-directives.
-
-@findex #pragma
-@findex #pragma GCC
-
-The ISO standard specifies that the effect of the @samp{#pragma}
-directive is implementation-defined. The GNU C preprocessor recognizes
-some pragmas, and passes unrecognized ones through to the preprocessor
-output, so they are available to the compilation pass.
-
-In line with the C99 standard, which introduces a STDC namespace for C99
-pragmas, the preprocessor introduces a GCC namespace for GCC pragmas.
-Supported GCC preprocessor pragmas are of the form @samp{#pragma GCC
-...}. For backwards compatibility previously supported pragmas are also
-recognized without the @samp{GCC} prefix, however that use is
-deprecated. Pragmas that are already deprecated are not recognized with
-a @samp{GCC} prefix.
-
-@findex #pragma GCC dependency
-The @samp{#pragma GCC dependency} allows you to check the relative dates
-of the current file and another file. If the other file is more recent
-than the current file, a warning is issued. This is useful if the
-include file is derived from the other file, and should be regenerated.
-The other file is searched for using the normal include search path.
-Optional trailing text can be used to give more information in the
-warning message.
+@noindent
+will not produce an error.
-@smallexample
-#pragma GCC dependency "parse.y"
-#pragma GCC dependency "/usr/include/time.h" rerun /path/to/fixincludes
-@end smallexample
-
-@findex _Pragma
-The C99 standard also introduces the @samp{_Pragma} operator. The
-syntax is @code{_Pragma (string-literal)}, where @samp{string-literal}
-can be either a normal or wide-character string literal. It is
-destringized, by replacing all @samp{\\} with a single @samp{\} and all
-@samp{\"} with a @samp{"}. The result is then processed as if it had
-appeared as the right hand side of a @samp{#pragma} directive. For
-example,
+@item #pragma GCC system_header
+This pragma takes no arguments. It causes the rest of the code in the
+current file to be treated as if it came from a system header.
+@xref{System Headers}.
-@smallexample
-_Pragma ("GCC dependency \"parse.y\"")
-@end smallexample
+@end ftable
-@noindent has the same effect as @samp{#pragma GCC dependency
-"parse.y"}. The same effect could be achieved using macros, for example
+@node Other Directives
+@chapter Other Directives
-@smallexample
-#define DO_PRAGMA(x) _Pragma (#x)
-DO_PRAGMA (GCC dependency "parse.y")
-@end smallexample
+@findex #ident
+The @samp{#ident} directive takes one argument, a string constant. On
+some systems, that string constant is copied into a special segment of
+the object file. On other systems, the directive is ignored.
-The standard is unclear on where a @samp{_Pragma} operator can appear.
-The preprocessor accepts it even within a preprocessing conditional
-directive like @samp{#if}. To be safe, you are probably best keeping it
-out of directives other than @samp{#define}, and putting it on a line of
-its own.
+This directive is not part of the C standard, but it is not an official
+GNU extension either. We believe it came from System V.
-@findex #ident
-The @samp{#ident} directive is supported for compatibility with certain
-other systems. It is followed by a line of text. On some systems, the
-text is copied into a special place in the object file; on most systems,
-the text is ignored and this directive has no effect. Typically
-@samp{#ident} is only used in header files supplied with those systems
-where it is meaningful.
+@findex #sccs
+The @samp{#sccs} directive is recognized on some systems, because it
+appears in their header files. It is a very old, obscure, extension
+which we did not invent, and we have been unable to find any
+documentation of what it should do, so GCC simply ignores it.
@cindex null directive
The @dfn{null directive} consists of a @samp{#} followed by a newline,
produce no output, rather than a line of output containing just a
@samp{#}. Supposedly some old C programs contain such lines.
-@node Output, Implementation, Other Directives, Top
-@section C Preprocessor Output
+@node Preprocessor Output
+@chapter Preprocessor Output
+
+When the C preprocessor is used with the C, C++, or Objective C
+compilers, it is integrated into the compiler and communicates a stream
+of binary tokens directly to the compiler's parser. However, it can
+also be used in the more conventional standalone mode, where it produces
+textual output.
+@c FIXME: Document the library interface.
@cindex output format
The output from the C preprocessor looks much like the input, except
that all preprocessing directive lines have been replaced with blank
-lines and all comments with spaces.
+lines and all comments with spaces. Long runs of blank lines are
+discarded.
The ISO standard specifies that it is implementation defined whether a
preprocessor preserves whitespace between tokens, or replaces it with
the first token on a non-directive line is preceded with sufficient
spaces that it appears in the same column in the preprocessed output
that it appeared in in the original source file. This is so the output
-is easy to read. @xref{Unreliable Features}.
+is easy to read. @xref{Differences from previous versions}. CPP does
+not insert any whitespace where there was none in the original source,
+except where necessary to prevent an accidental token paste.
+@cindex linemarkers
Source file name and line number information is conveyed by lines
of the form
@end example
@noindent
-which are inserted as needed into the output (but never within a string
-or character constant), and in place of long sequences of empty lines.
-Such a line means that the following line originated in file
-@var{filename} at line @var{linenum}.
+These are called @dfn{linemarkers}. They are inserted as needed into
+the output (but never within a string or character constant). They mean
+that the following line originated in file @var{filename} at line
+@var{linenum}.
After the file name comes zero or more flags, which are @samp{1},
@samp{2}, @samp{3}, or @samp{4}. If there are multiple flags, spaces
This indicates that the following text comes from a system header file,
so certain warnings should be suppressed.
@item 4
-This indicates that the following text should be treated as C@.
+This indicates that the following text should be treated as being
+wrapped in an implicit @samp{extern "C"} block.
@c maybe cross reference NO_IMPLICIT_EXTERN_C
@end table
-@node Implementation, Unreliable Features, Output, Top
-@section Implementation-defined Behavior and Implementation Limits
-@cindex implementation limits
-@cindex implementation-defined behavior
+Some directives may be duplicated in the output of the preprocessor.
+These are @samp{#ident} (always), @samp{#pragma} (only if the
+preprocessor does not handle the pragma itself), and @samp{#define} and
+@samp{#undef} (with certain debugging options). If this happens, the
+@samp{#} of the directive will always be in the first column, and there
+will be no space between the @samp{#} and the directive name. If macro
+expansion happens to generate tokens which might be mistaken for a
+duplicated directive, a space will be inserted between the @samp{#} and
+the directive name.
+
+@node Traditional Mode
+@chapter Traditional Mode
+
+Traditional (pre-standard) C preprocessing is rather different from
+the preprocessing specified by the standard. When GCC is given the
+@option{-traditional} option, it attempts to emulate a traditional
+preprocessor. We do not guarantee that GCC's behavior under
+@option{-traditional} matches any pre-standard preprocessor exactly.
+
+Traditional mode exists only for backward compatibility. We have no
+plans to augment it in any way nor will we change it except to fix
+catastrophic bugs. You should be aware that modern C libraries often
+have header files which are incompatible with traditional mode.
+
+This is a list of the differences. It may not be complete, and may not
+correspond exactly to the behavior of either GCC or a true traditional
+preprocessor.
+
+@itemize @bullet
+@item
+Traditional macro expansion pays no attention to single-quote or
+double-quote characters; macro argument symbols are replaced by the
+argument values even when they appear within apparent string or
+character constants.
+
+@item
+Traditionally, it is permissible for a macro expansion to end in the
+middle of a string or character constant. The constant continues into
+the text surrounding the macro call.
+
+@item
+However, the end of the line terminates a string or character constant,
+with no error. (This is a kluge. Traditional mode is commonly used to
+preprocess things which are not C, and have a different comment syntax.
+Single apostrophes often appear in comments. This kluge prevents the
+traditional preprocessor from issuing errors on such comments.)
+
+@item
+Preprocessing directives are recognized in traditional C only when their
+leading @samp{#} appears in the first column. There can be no
+whitespace between the beginning of the line and the @samp{#}.
+
+@item
+In traditional C, a comment is equivalent to no text at all. (In ISO
+C, a comment counts as whitespace.) It can be used sort of the same way
+that @samp{##} is used in ISO C, to paste macro arguments together.
+
+@item
+Traditional C does not have the concept of a preprocessing number.
+
+@item
+A macro is not suppressed within its own definition, in traditional C@.
+Thus, any macro that is used recursively inevitably causes an error.
+
+@item
+The @samp{#} and @samp{##} operators are not available in traditional
+C@.
+
+@item
+In traditional C, the text at the end of a macro expansion can run
+together with the text after the macro call, to produce a single token.
+This is impossible in ISO C@.
+
+@item
+None of the GNU extensions to the preprocessor are available in
+traditional mode, with the exception of assertions, and those may be
+removed in the future.
+
+@item
+A true traditional C preprocessor does not recognize @samp{#elif},
+@samp{#error}, or @samp{#pragma}. GCC supports @samp{#elif} and
+@samp{#error} even in traditional mode, but not @samp{#pragma}.
+
+@item
+Traditional mode is text-based, not token-based, and comments are
+stripped after macro expansion. Therefore, @samp{/**/} can be used to
+paste tokens together provided that there is no whitespace between it
+and the tokens to be pasted.
+
+@item
+Traditional mode preserves the amount and form of whitespace provided by
+the user. Hard tabs remain hard tabs. This can be useful, e.g. if you
+are preprocessing a Makefile (which we do not encourage).
+@end itemize
+
+You can request warnings about features that did not exist, or worked
+differently, in traditional C with the @option{-Wtraditional} option.
+This works only if you do @emph{not} specify @option{-traditional}. GCC
+does not warn about features of ISO C which you must use when you are
+using a conforming compiler, such as the @samp{#} and @samp{##}
+operators.
-The ISO C standard mandates that implementations document various
-aspects of preprocessor behavior. You should try to avoid undue
+Presently @option{-Wtraditional} warns about:
+
+@itemize @bullet
+@item
+Macro parameters that appear within string literals in the macro body.
+In traditional C macro replacement takes place within string literals,
+but does not in ISO C@.
+
+@item
+In traditional C, some preprocessor directives did not exist.
+Traditional preprocessors would only consider a line to be a directive
+if the @samp{#} appeared in column 1 on the line. Therefore
+@option{-Wtraditional} warns about directives that traditional C
+understands but would ignore because the @samp{#} does not appear as the
+first character on the line. It also suggests you hide directives like
+@samp{#pragma} not understood by traditional C by indenting them. Some
+traditional implementations would not recognise @samp{#elif}, so it
+suggests avoiding it altogether.
+
+@item
+A function-like macro that appears without an argument list. In
+traditional C this was an error. In ISO C it merely means that the
+macro is not expanded.
+
+@item
+The unary plus operator. This did not exist in traditional C@.
+
+@item
+The @samp{U} and @samp{LL} integer constant suffixes, which were not
+available in traditional C@. (Traditional C does support the @samp{L}
+suffix for simple long integer constants.) You are not warned about
+uses of these suffixes in macros defined in system headers. For
+instance, @samp{UINT_MAX} may well be defined as @samp{4294967295U}, but
+you will not be warned if you use @samp{UINT_MAX}.
+
+You can usually avoid the warning, and the related warning about
+constants which are so large that they are unsigned, by writing the
+integer constant in question in hexadecimal, with no U suffix. Take
+care, though, because this gives the wrong result in exotic cases.
+@end itemize
+
+@node Implementation Details
+@chapter Implementation Details
+
+Here we document details of how the preprocessor's implementation
+affects its user-visible behavior. You should try to avoid undue
reliance on behaviour described here, as it is possible that it will
change subtly in future implementations.
-@itemize @bullet
+Also documented here are obsolete features and changes from previous
+versions of GNU CPP.
+
+@menu
+* Implementation-defined behavior::
+* Implementation limits::
+* Obsolete Features::
+* Differences from previous versions::
+@end menu
+@node Implementation-defined behavior
+@section Implementation-defined behavior
+@cindex implementation-defined behavior
+
+This is how GNU CPP behaves in all the cases which the C standard
+describes as @dfn{implementation-defined}. This term means that the
+implementation is free to do what it likes, but must document its choice
+and stick to it.
+@c FIXME: Check the C++ standard for more implementation-defined stuff.
+
+@itemize @bullet
+@need 1000
@item The mapping of physical source file multi-byte characters to the
execution character set.
@item Non-empty sequences of whitespace characters.
-Each whitespace sequence is not preserved, but collapsed to a single
+In textual output, each whitespace sequence is collapsed to a single
space. For aesthetic reasons, the first token on each non-directive
line of output is preceded with sufficient spaces that it appears in the
same column as it did in the original source file.
Multi-character character constants are interpreted a character at a
time, shifting the previous result left by the number of bits per
character on the host, and adding the new character. For example, 'ab'
-on an 8-bit host would be interpreted as 'a' * 256 + 'b'. If there are
-more characters in the constant than can fit in the widest native
+on an 8-bit host would be interpreted as @w{'a' * 256 + 'b'}. If there
+are more characters in the constant than can fit in the widest native
integer type on the host, usually a @samp{long}, the excess characters
are ignored and a diagnostic is given.
@item Source file inclusion.
For a discussion on how the preprocessor locates header files,
-@pxref{Include Operation}.
+@ref{Include Operation}.
@item Interpretation of the filename resulting from a macro-expanded
@samp{#include} directive.
-If the macro expands to a string literal, the @samp{#include} directive
-is processed as if the string had been specified directly. Otherwise,
-the macro must expand to a token stream beginning with a @samp{<} token
-and including a @samp{>} token. In this case, the tokens between the
-@samp{<} and the first @samp{>} are combined to form the filename to be
-included. Any whitespace between tokens is reduced to a single space;
-then any space after the initial @samp{<} is retained, but a trailing
-space before the closing @samp{>} is ignored.
-
-In either case, if any excess tokens remain, an error occurs and the
-directive is not processed.
+@xref{Computed Includes}.
@item Treatment of a @samp{#pragma} directive that after macro-expansion
results in a standard pragma.
-The pragma is processed as if it were a normal standard pragma.
+No macro expansion occurs on any @samp{#pragma} directive line, so the
+question does not arise.
+
+Note that GCC does not yet implement any of the standard
+pragmas.
@end itemize
-The following documents internal limits of GNU cpp.
+@node Implementation limits
+@section Implementation limits
+@cindex implementation limits
+
+GNU CPP has a small number of internal limits. This section lists the
+limits which the C standard requires to be no lower than some minimum,
+and all the others we are aware of. We intend there to be as few limits
+as possible. If you encounter an undocumented or inconvenient limit,
+please report that to us as a bug. (See the section on reporting bugs in
+the GCC manual.)
+
+Where we say something is limited @dfn{only by available memory}, that
+means that internal data structures impose no intrinsic limit, and space
+is allocated with @code{malloc} or equivalent. The actual limit will
+therefore depend on many things, such as the size of other things
+allocated by the compiler at the same time, the amount of memory
+consumed by other processes on the same computer, etc.
@itemize @bullet
@item Levels of parenthesised expressions within a full expression.
The C standard requires this to be at least 63. In preprocessor
-conditional expressions it is limited only by available memory.
+conditional expressions, it is limited only by available memory.
@item Significant initial characters in an identifier or macro name.
@item Number of parameters in a macro definition and arguments in a macro call.
-We allow USHRT_MAX, which is normally 65,535, and above the minimum of
-127 required by the standard.
+We allow @code{USHRT_MAX}, which is no smaller than 65,535. The minimum
+required by the standard is 127.
@item Number of characters on a logical source line.
-The C standard requires a minimum of 4096 be permitted. GNU cpp places
+The C standard requires a minimum of 4096 be permitted. GNU CPP places
no limits on this, but you may get incorrect column numbers reported in
diagnostics for lines longer than 65,535 characters.
+@item Maximum size of a source file.
+
+The standard does not specify any lower limit on the maximum size of a
+source file. GNU cpp maps files into memory, so it is limited by the
+available address space. This is generally at least two gigabytes.
+Depending on the operating system, the size of physical memory may or
+may not be a limitation.
+
@end itemize
-@node Unreliable Features, Invocation, Implementation, Top
-@section Undefined Behavior and Deprecated Features
-@cindex undefined behavior
-@cindex deprecated features
+@node Obsolete Features
+@section Obsolete Features
+
+GNU CPP has a number of features which are present mainly for
+compatibility with older programs. We discourage their use in new code.
+In some cases, we plan to remove the feature in a future version of GCC.
-This section details GNU C preprocessor behavior that is subject to
-change or deprecated. You are @emph{strongly advised} to write your
-software so it does not rely on anything described here; future versions
-of the preprocessor may subtly change such behavior or even remove the
-feature altogether.
+@menu
+* Assertions::
+* Obsolete once-only headers::
+* Miscellaneous obsolete features::
+@end menu
-Preservation of the form of whitespace between tokens is unlikely to
-change from current behavior (@ref{Output}), but you are advised not
-to rely on it.
+@node Assertions
+@subsection Assertions
+@cindex assertions
-The following are undocumented and subject to change:-
+@dfn{Assertions} are a deprecated alternative to macros in writing
+conditionals to test what sort of computer or system the compiled
+program will run on. Assertions are usually predefined, but you can
+define them with preprocessing directives or command-line options.
-@itemize @bullet
+Assertions were intended to provide a more systematic way to describe
+the compiler's target system. However, in practice they are just as
+unpredictable as the system-specific predefined macros. In addition, they
+are not part of any standard, and only a few compilers support them.
+Therefore, the use of assertions is @strong{less} portable than the use
+of system-specific predefined macros. We recommend you do not use them at
+all.
-@item Precedence of ## operators with respect to each other
+@cindex predicates
+An assertion looks like this:
-Whether a sequence of ## operators is evaluated left-to-right,
-right-to-left or indeed in a consistent direction at all is not
-specified. An example of where this might matter is pasting the
-arguments @samp{1}, @samp{e} and @samp{-2}. This would be fine for
-left-to-right pasting, but right-to-left pasting would produce an
-invalid token @samp{e-2}. It is possible to guarantee precedence by
-suitable use of nested macros.
+@example
+#@var{predicate} (@var{answer})
+@end example
-@item Precedence of # operator with respect to the ## operator
+@noindent
+@var{predicate} must be a single identifier. @var{answer} can be any
+sequence of tokens; all characters are significant except for leading
+and trailing whitespace, and differences in internal whitespace
+sequences are ignored. (This is similar to the rules governing macro
+redefinition.) Thus, @samp{(x + y)} is different from @samp{(x+y)} but
+equivalent to @samp{@w{( x + y )}}. Parentheses do not nest inside an
+answer.
-Which of these two operators is evaluated first is not specified.
+@cindex testing predicates
+To test an assertion, you write it in an @samp{#if}. For example, this
+conditional succeeds if either @code{vax} or @code{ns16000} has been
+asserted as an answer for @code{machine}.
-@end itemize
+@example
+#if #machine (vax) || #machine (ns16000)
+@end example
-The following features are in flux and should not be used in portable
-code:
+@noindent
+You can test whether @emph{any} answer is asserted for a predicate by
+omitting the answer in the conditional:
-@itemize @bullet
+@example
+#if #machine
+@end example
-@item Optional argument when invoking rest argument macros
+@findex #assert
+Assertions are made with the @samp{#assert} directive. Its sole
+argument is the assertion to make, without the leading @samp{#} that
+identifies assertions in conditionals.
-As an extension, GCC permits you to omit the variable arguments entirely
-when you use a variable argument macro. This works whether or not you
-give the variable argument a name. For example, the two macro
-invocations in the example below expand to the same thing:
+@example
+#assert @var{predicate} (@var{answer})
+@end example
-@smallexample
-#define debug(format, ...) printf (format, __VA_ARGS__)
-debug("string"); /* Not permitted by C standard. */
-debug("string",); /* OK. */
-@end smallexample
+@noindent
+You may make several assertions with the same predicate and different
+answers. Subsequent assertions do not override previous ones for the
+same predicate. All the answers for any given predicate are
+simultaneously true.
-This extension will be preserved, but the special behavior of @samp{##}
-in this context has changed in the past and may change again in the
-future.
+@cindex assertions, cancelling
+@findex #unassert
+Assertions can be cancelled with the the @samp{#unassert} directive. It
+has the same syntax as @samp{#assert}. In that form it cancels only the
+answer which was specified on the @samp{#unassert} line; other answers
+for that predicate remain true. You can cancel an entire predicate by
+leaving out the answer:
-@item ## swallowing preceding text in rest argument macros
+@example
+#unassert @var{predicate}
+@end example
-Formerly, in a macro expansion, if @samp{##} appeared before a variable
-arguments parameter, and the set of tokens specified for that argument in
-the macro invocation was empty, previous versions of the GNU C
-preprocessor would back up and remove the preceding sequence of
-non-whitespace characters (@strong{not} the preceding token). This
-extension is in direct conflict with the 1999 C standard and has been
-drastically pared back.
+@noindent
+In either form, if no such assertion has been made, @samp{#unassert} has
+no effect.
-In the current version of the preprocessor, if @samp{##} appears between
-a comma and a variable arguments parameter, and the variable argument is
-omitted entirely, the comma will be removed from the expansion. If the
-variable argument is empty, or the token before @samp{##} is not a
-comma, then @samp{##} behaves as a normal token paste.
+You can also make or cancel assertions using command line options.
+@xref{Invocation}.
-Portable code should avoid this extension at all costs.
+@node Obsolete once-only headers
+@subsection Obsolete once-only headers
-@end itemize
+GNU C supports two more ways of indicating that a header file should be
+read only once. Neither one is as portable as a wrapper @samp{#ifndef},
+and we recommend you do not use them in new programs.
+
+@findex #import
+In the Objective C language, there is a variant of @samp{#include}
+called @samp{#import} which includes a file, but does so at most once.
+If you use @samp{#import} instead of @samp{#include}, then you don't
+need the conditionals inside the header file to prevent multiple
+inclusion of the contents. GCC permits the use of @samp{#import} in C
+and C++ as well as Objective C. However, it is not in standard C or C++
+and should therefore not be used by portable programs.
+
+@samp{#import} is not a well designed feature. It requires the users of
+a header file to know that it should only be included once. It is much
+better for the header file's implementor to write the file so that users
+don't need to know this. Using a wrapper @samp{#ifndef} accomplishes
+this goal.
-The following features are deprecated and will likely be removed at some
-point in the future:-
+In the present implementation, a single use of @samp{#import} will
+prevent the file from ever being read again, by either @samp{#import} or
+@samp{#include}. You should not rely on this; do not use both
+@samp{#import} and @samp{#include} to refer to the same header file.
-@itemize @bullet
+Another way to prevent a header file from being included more than once
+is with the @samp{#pragma once} directive. If @samp{#pragma once} is
+seen when scanning a header file, that file will never be read again, no
+matter what.
+
+@samp{#pragma once} does not have the problems that @samp{#import} does,
+but it is not recognized by all preprocessors, so you cannot rely on it
+in a portable program.
+@node Miscellaneous obsolete features
+@subsection Miscellaneous obsolete features
+
+Here are a few more obsolete features.
+
+@itemize @bullet
+@cindex invalid token paste
@item Attempting to paste two tokens which together do not form a valid
-preprocessing token
+preprocessing token.
The preprocessor currently warns about this and outputs the two tokens
adjacently, which is probably the behavior the programmer intends. It
is being used superstitiously, to guard against whitespace appearing
between two tokens. It is almost always safe to delete the @samp{##}.
-@findex #pragma once
-@item #pragma once
+@cindex pragma poison
+@item @code{#pragma poison}
+
+This is the same as @samp{#pragma GCC poison}. The version without the
+@code{GCC} prefix is deprecated. @xref{Pragmas}.
-This pragma was once used to tell the preprocessor that it need not
-include a file more than once. It is now obsolete and should not be
-used at all.
+@cindex multi-line string constants
+@item Multi-line string constants
-@item #pragma poison
+GCC currently allows a string constant to extend across multiple logical
+lines of the source file. This extension is deprecated and will be
+removed in a future version of GCC. Such string constants are already
+rejected in all directives apart from @samp{#define}.
-This pragma has been superseded by @samp{#pragma GCC poison}.
-@xref{Poisoning}.
+Instead, make use of ISO C concatenation of adjacent string literals, or
+use @samp{\n} followed by a backslash-newline.
-@item Multi-line string literals
+@end itemize
-The preprocessor currently allows raw newlines in string literals. This
-extension is deprecated and will be removed in a future version of GCC.
-The preprocessor already forbids such string literals in all directives
-apart from #define.
+@node Differences from previous versions
+@section Differences from previous versions
+@cindex differences from previous versions
-Instead, make use of ISO C concatenation of adjacent string literals, or
-use @samp{\n} followed by an escaped newline.
+This section details behavior which has changed from previous versions
+of GNU CPP. We do not plan to change it again in the near future, but
+we do not promise not to, either.
-@item Preprocessing things which are not C
+The ``previous versions'' discussed here are 2.95 and before. The
+behavior of GCC 3.0 is mostly the same as the behavior of the widely
+used 2.96 and 2.97 development snapshots. Where there are differences,
+they generally represent bugs in the snapshots.
-The C preprocessor is intended to be used only with C, C++, and
-Objective C source code. In the past, it has been abused as a general
-text processor. It will choke on input which is not lexically valid C;
-for example, apostrophes will be interpreted as the beginning of
-character constants, and cause errors. Also, you cannot rely on it
-preserving characteristics of the input which are not significant to
-C-family languages. For instance, if a Makefile is preprocessed, all
-the hard tabs will be lost, and the Makefile will not work.
+@itemize @bullet
-Having said that, you can often get away with using cpp on things which
-are not C. Other Algol-ish programming languages are often safe
-(Pascal, Ada, ...) and so is assembly, with caution. @samp{-traditional}
-mode is much more permissive, and can safely be used with e.g. Fortran.
-Many of the problems go away if you write C or C++ style comments
-instead of native language comments, and if you avoid elaborate macros.
+@item Order of evaluation of @samp{#} and @samp{##} operators
-Wherever possible, you should use a preprocessor geared to the language
-you are writing in. Modern versions of the GNU assembler have macro
-facilities. Most high level programming languages have their own
-conditional compilation and inclusion mechanism. If all else fails,
-try a true general text processor, such as @xref{Top, M4, , m4, GNU `m4'}.
+The standard does not specify the order of evaluation of a chain of
+@samp{##} operators, nor whether @samp{#} is evaluated before, after, or
+at the same time as @samp{##}. You should therefore not write any code
+which depends on any specific ordering. It is possible to guarantee an
+ordering, if you need one, by suitable use of nested macros.
+
+An example of where this might matter is pasting the arguments @samp{1},
+@samp{e} and @samp{-2}. This would be fine for left-to-right pasting,
+but right-to-left pasting would produce an invalid token @samp{e-2}.
+
+GCC 3.0 evaluates @samp{#} and @samp{##} at the same time and strictly
+left to right. Older versions evaluated all @samp{#} operators first,
+then all @samp{##} operators, in an unreliable order.
+
+@item The form of whitespace betwen tokens in preprocessor output
+
+@xref{Preprocessor Output}, for the current textual format. This is
+also the format used by stringification. Normally, the preprocessor
+communicates tokens directly to the compiler's parser, and whitespace
+does not come up at all.
+
+Older versions of GCC preserved all whitespace provided by the user and
+inserted lots more whitespace of their own, because they could not
+accurately predict when extra spaces were needed to prevent accidental
+token pasting.
+
+@item Optional argument when invoking rest argument macros
+
+As an extension, GCC permits you to omit the variable arguments entirely
+when you use a variable argument macro. This is forbidden by the 1999 C
+standard, and will provoke a pedantic warning with GCC 3.0. Previous
+versions accepted it silently.
+
+@item @samp{##} swallowing preceding text in rest argument macros
+
+Formerly, in a macro expansion, if @samp{##} appeared before a variable
+arguments parameter, and the set of tokens specified for that argument in
+the macro invocation was empty, previous versions of the GNU C
+preprocessor would back up and remove the preceding sequence of
+non-whitespace characters (@strong{not} the preceding token). This
+extension is in direct conflict with the 1999 C standard and has been
+drastically pared back.
+In the current version of the preprocessor, if @samp{##} appears between
+a comma and a variable arguments parameter, and the variable argument is
+omitted entirely, the comma will be removed from the expansion. If the
+variable argument is empty, or the token before @samp{##} is not a
+comma, then @samp{##} behaves as a normal token paste.
+
+@item Traditional mode and GNU extensions
+
+Traditional mode used to be implemented in the same program as normal
+preprocessing. Therefore, all the GNU extensions to the preprocessor
+were still available in traditional mode. It is now a separate program,
+and does not implement any of the GNU extensions except assertions.
+Even those may be removed in a future release.
@end itemize
-@node Invocation, Concept Index, Unreliable Features, Top
-@section Invoking the C Preprocessor
-@cindex invocation of the preprocessor
+@node Invocation
+@chapter Invocation
+@cindex invocation
+@cindex command line
Most often when you use the C preprocessor you will not have to invoke it
explicitly: the C compiler will do so automatically. However, the
-preprocessor is sometimes useful on its own.
+preprocessor is sometimes useful on its own. All the options listed
+here are also acceptable to the C compiler and have the same meaning,
+except that the C compiler has different rules for specifying the output
+file.
+
+@strong{Note:} Whether you use the preprocessor by way of @command{gcc}
+or @command{cpp}, the @dfn{compiler driver} is run first. This
+program's purpose is to translate your command into invocations of the
+programs that do the actual work. Their command line interfaces are
+similar but not identical to the documented interface, and may change
+without notice.
@ignore
@c man begin SYNOPSIS
-cpp [@samp{-P}] [@samp{-C}] [@samp{-gcc}] [@samp{-traditional}]
- [@samp{-undef}] [@samp{-trigraphs}] [@samp{-pedantic}]
- [@samp{-W}@var{warn}...] [@samp{-I}@var{dir}...]
- [@samp{-D}@var{macro}[=@var{defn}]...] [@samp{-U}@var{macro}]
- [@samp{-A}@var{predicate}(@var{answer})]
- [@samp{-M}|@samp{-MM}][@samp{-MG}][@samp{-MF}@var{filename}]
- [@samp{-MP}][@samp{-MQ}@var{target}...][@samp{-MT}@var{target}...]
- [@samp{-x} @var{language}] [@samp{-std=}@var{standard}]
+cpp [@option{-D}@var{macro}[=@var{defn}]...] [@option{-U}@var{macro}]
+ [@option{-I}@var{dir}...] [@option{-W}@var{warn}...]
+ [@option{-M}|@option{-MM}] [@option{-MG}] [@option{-MF} @var{filename}]
+ [@option{-MP}] [@option{-MQ} @var{target}...] [@option{-MT} @var{target}...]
+ [@option{-x} @var{language}] [@option{-std=}@var{standard}]
@var{infile} @var{outfile}
Only the most useful options are listed here; see below for the remainder.
other files it specifies with @samp{#include}. All the output generated
by the combined input files is written in @var{outfile}.
-Either @var{infile} or @var{outfile} may be @samp{-}, which as
+Either @var{infile} or @var{outfile} may be @option{-}, which as
@var{infile} means to read from standard input and as @var{outfile}
means to write to standard output. Also, if either file is omitted, it
-means the same as if @samp{-} had been specified for that file.
+means the same as if @option{-} had been specified for that file.
+
+All single-letter options which take an argument may have that argument
+appear immediately after the option letter, or with a space between
+option and argument: @option{-Ifoo} and @option{-I foo} have the same
+effect. Long options that take arguments require a space between option
+and argument.
@cindex options
-Here is a table of command options accepted by the C preprocessor.
-These options can also be given when compiling a C program; they are
-passed along automatically to the preprocessor when it is invoked by the
-compiler.
+@table @code
+@item -D @var{name}
+Predefine @var{name} as a macro, with definition @samp{1}.
-@table @samp
-@item -P
-@findex -P
-Inhibit generation of @samp{#}-lines with line-number information in the
-output from the preprocessor. This might be useful when running the
-preprocessor on something that is not C code and will be sent to a
-program which might be confused by the @samp{#}-lines. @xref{Output}.
+@item -D @var{name}=@var{definition}
+Predefine @var{name} as a macro, with definition @var{definition}.
+There are no restrictions on the contents of @var{definition}, but if
+you are invoking the preprocessor from a shell or shell-like program you
+may need to use the shell's quoting syntax to protect characters such as
+spaces that have a meaning in the shell syntax. If you use more than
+one @option{-D} for the same @var{name}, the rightmost definition takes
+effect.
-@item -C
-@findex -C
-Do not discard comments. All comments are passed through to the output
-file, except for comments in processed directives, which are deleted
-along with the directive. Comments appearing in the expansion list of a
-macro will be preserved, and appear in place wherever the macro is
-invoked.
+If you wish to define a function-like macro on the command line, write
+its argument list with surrounding parentheses before the equals sign
+(if any). Parentheses are meaningful to most shells, so you will need
+to quote the option. With @command{sh} and @command{csh},
+@option{-D'@var{name}(@var{args...})=@var{definition}'} works.
-You should be prepared for side effects when using @samp{-C}; it causes
-the preprocessor to treat comments as tokens in their own right. For
-example, macro redefinitions that were trivial when comments were
-replaced by a single space might become significant when comments are
-retained. Also, comments appearing at the start of what would be a
-directive line have the effect of turning that line into an ordinary
-source line, since the first token on the line is no longer a @samp{#}.
-
-@item -traditional
-@findex -traditional
-Try to imitate the behavior of old-fashioned C, as opposed to ISO C@.
-
-@itemize @bullet
-@item
-Traditional macro expansion pays no attention to single-quote or
-double-quote characters; macro argument symbols are replaced by the
-argument values even when they appear within apparent string or
-character constants.
-
-@item
-Traditionally, it is permissible for a macro expansion to end in the
-middle of a string or character constant. The constant continues into
-the text surrounding the macro call.
-
-@item
-However, traditionally the end of the line terminates a string or
-character constant, with no error.
-
-@item
-In traditional C, a comment is equivalent to no text at all. (In ISO
-C, a comment counts as whitespace.)
-
-@item
-Traditional C does not have the concept of a ``preprocessing number''.
-It considers @samp{1.0e+4} to be three tokens: @samp{1.0e}, @samp{+},
-and @samp{4}.
-
-@item
-A macro is not suppressed within its own definition, in traditional C@.
-Thus, any macro that is used recursively inevitably causes an error.
-
-@item
-The character @samp{#} has no special meaning within a macro definition
-in traditional C@.
-
-@item
-In traditional C, the text at the end of a macro expansion can run
-together with the text after the macro call, to produce a single token.
-(This is impossible in ISO C@.)
-
-@item
-None of the GNU extensions to the preprocessor are available in
-@samp{-traditional} mode.
-
-@end itemize
-
-@cindex Fortran
-@cindex unterminated
-Use the @samp{-traditional} option when preprocessing Fortran code, so
-that single-quotes and double-quotes within Fortran comment lines (which
-are generally not recognized as such by the preprocessor) do not cause
-diagnostics about unterminated character or string constants.
-
-However, this option does not prevent diagnostics about unterminated
-comments when a C-style comment appears to start, but not end, within
-Fortran-style commentary.
-
-So, the following Fortran comment lines are accepted with
-@samp{-traditional}:
-
-@smallexample
-C This isn't an unterminated character constant
-C Neither is "20000000000, an octal constant
-C in some dialects of Fortran
-@end smallexample
-
-However, this type of comment line will likely produce a diagnostic, or
-at least unexpected output from the preprocessor, due to the
-unterminated comment:
-
-@smallexample
-C Some Fortran compilers accept /* as starting
-C an inline comment.
-@end smallexample
-
-@cindex g77
-Note that @code{g77} automatically supplies the @samp{-traditional}
-option when it invokes the preprocessor. However, a future version of
-@code{g77} might use a different, more-Fortran-aware preprocessor in
-place of @code{cpp}.
-
-@item -trigraphs
-@findex -trigraphs
-Process ISO standard trigraph sequences. These are three-character
-sequences, all starting with @samp{??}, that are defined by ISO C to
-stand for single characters. For example, @samp{??/} stands for
-@samp{\}, so @samp{'??/n'} is a character constant for a newline. By
-default, GCC ignores trigraphs, but in standard-conforming modes it
-converts them. See the @samp{-std} option.
-
-The nine trigraph sequences are
-@table @samp
-@item ??(
--> @samp{[}
-
-@item ??)
--> @samp{]}
-
-@item ??<
--> @samp{@{}
-
-@item ??>
--> @samp{@}}
-
-@item ??=
--> @samp{#}
-
-@item ??/
--> @samp{\}
-
-@item ??'
--> @samp{^}
+@item -U @var{name}
+Cancel any previous definition of @var{name}, either built in or
+provided with a @option{-D} option.
-@item ??!
--> @samp{|}
+All @option{-imacros @var{file}} and @option{-include @var{file}} options
+are processed after all @option{-D} and @option{-U} options.
-@item ??-
--> @samp{~}
+@item -undef
+Do not predefine any system-specific macros. The common predefined
+macros remain defined.
-@end table
+@item -I @var{dir}
+Add the directory @var{dir} to the list of directories to be searched
+for header files. @xref{Search Path}. Directories named by @option{-I}
+are searched before the standard system include directories.
-Trigraph support is not popular, so many compilers do not implement it
-properly. Portable code should not rely on trigraphs being either
-converted or ignored.
+It is dangerous to specify a standard system include directory in an
+@option{-I} option. This defeats the special treatment of system
+headers (@pxref{System Headers}). It can also defeat the repairs to
+buggy system headers which GCC makes when it is installed.
-@item -pedantic
-@findex -pedantic
-Issue warnings required by the ISO C standard in certain cases such
-as when text other than a comment follows @samp{#else} or @samp{#endif}.
+@item -o @var{file}
+Write output to @var{file}. This is the same as specifying @var{file}
+as the second non-option argument to @command{cpp}. @command{gcc} has a
+different interpretation of a second non-option argument, so you must
+use @option{-o} to specify the output file.
-@item -pedantic-errors
-@findex -pedantic-errors
-Like @samp{-pedantic}, except that errors are produced rather than
-warnings.
+@item -Wall
+Turns on all optional warnings which are desirable for normal code. At
+present this is @option{-Wcomment} and @option{-Wtrigraphs}. Note that
+many of the preprocessor's warnings are on by default and have no
+options to control them.
@item -Wcomment
-@findex -Wcomment
@itemx -Wcomments
-(Both forms have the same effect).
Warn whenever a comment-start sequence @samp{/*} appears in a @samp{/*}
comment, or whenever a backslash-newline appears in a @samp{//} comment.
+(Both forms have the same effect.)
@item -Wtrigraphs
-@findex -Wtrigraphs
Warn if any trigraphs are encountered. This option used to take effect
-only if @samp{-trigraphs} was also specified, but now works
+only if @option{-trigraphs} was also specified, but now works
independently. Warnings are not given for trigraphs within comments, as
-we feel this is obnoxious.
-
-@item -Wall
-@findex -Wall
-Requests @samp{-Wcomment} and @samp{-Wtrigraphs} (but not
-@samp{-Wtraditional} or @samp{-Wundef}).
+they do not affect the meaning of the program.
@item -Wtraditional
-@findex -Wtraditional
Warn about certain constructs that behave differently in traditional and
ISO C@. Also warn about ISO C constructs that have no traditional C
-equivalent, and/or problematic constructs which should be avoided.
+equivalent, and problematic constructs which should be avoided.
+@xref{Traditional Mode}.
-@itemize @bullet
-@item
-Macro parameters that appear within string literals in the macro body.
-In traditional C macro replacement takes place within string literals,
-but does not in ISO C.
-
-@item
-In traditional C, some preprocessor directives did not exist.
-Traditional preprocessors would only consider a line to be a directive
-if the @samp{#} appeared in column 1 on the line. Therefore
-@samp{-Wtraditional} warns about directives that traditional C
-understands but would ignore because the @samp{#} does not appear as the
-first character on the line. It also suggests you hide directives like
-@samp{#pragma} not understood by traditional C by indenting them. Some
-traditional implementations would not recognise @samp{#elif}, so it
-suggests avoiding it altogether.
-
-@item
-A function-like macro that appears without arguments.
-
-@item
-The unary plus operator.
-
-@item
-The `U' integer constant suffix. (Traditonal C does support the `L'
-suffix on integer constants.) Note, these suffixes appear in macros
-defined in the system headers of most modern systems, e.g. the _MIN/_MAX
-macros in limits.h. Use of these macros in user code might normally
-lead to spurious warnings, however gcc's integrated preprocessor has
-enough context to avoid warning in these cases.
-@end itemize
+@item -Wimport
+Warn the first time @samp{#import} is used.
@item -Wundef
-@findex -Wundef
-Warn if an undefined identifier is evaluated in an @samp{#if} directive.
-
-@item -I @var{directory}
-@findex -I
-Add the directory @var{directory} to the head of the list of
-directories to be searched for header files (@pxref{Include Syntax}).
-This can be used to override a system header file, substituting your
-own version, since these directories are searched before the system
-header file directories. If you use more than one @samp{-I} option,
-the directories are scanned in left-to-right order; the standard
-system directories come after.
-
-@item -I-
-Any directories specified with @samp{-I} options before the @samp{-I-}
-option are searched only for the case of @samp{#include "@var{file}"};
-they are not searched for @samp{#include <@var{file}>}.
-
-If additional directories are specified with @samp{-I} options after
-the @samp{-I-}, these directories are searched for all @samp{#include}
-directives.
-
-In addition, the @samp{-I-} option inhibits the use of the current
-directory as the first search directory for @samp{#include "@var{file}"}.
-Therefore, the current directory is searched only if it is requested
-explicitly with @samp{-I.}. Specifying both @samp{-I-} and @samp{-I.}
-allows you to control precisely which directories are searched before
-the current one and which are searched after.
-
-@item -nostdinc
-@findex -nostdinc
-Do not search the standard system directories for header files.
-Only the directories you have specified with @samp{-I} options
-(and the current directory, if appropriate) are searched.
-
-By using both @samp{-nostdinc} and @samp{-I-}, you can limit the include-file
-search path to only those directories you specify explicitly.
-
-@item -nostdinc++
-@findex -nostdinc++
-Do not search for header files in the C++-specific standard directories,
-but do still search the other standard directories. (This option is
-used when building the C++ library.)
-
-@item -remap
-@findex -remap
-When searching for a header file in a directory, remap file names if a
-file named @file{header.gcc} exists in that directory. This can be used
-to work around limitations of file systems with file name restrictions.
-The @file{header.gcc} file should contain a series of lines with two
-tokens on each line: the first token is the name to map, and the second
-token is the actual name to use.
-
-@item -D @var{name}
-@findex -D
-Predefine @var{name} as a macro, with definition @samp{1}.
-
-@item -D @var{name}=@var{definition}
-Predefine @var{name} as a macro, with definition @var{definition}.
-There are no restrictions on the contents of @var{definition}, but if
-you are invoking the preprocessor from a shell or shell-like program you
-may need to use the shell's quoting syntax to protect characters such as
-spaces that have a meaning in the shell syntax. If you use more than
-one @samp{-D} for the same @var{name}, the rightmost definition takes
-effect.
-
-Any @samp{-D} and @samp{-U} options on the command line are processed in
-order, and always before @samp{-imacros @var{file}}, regardless of the
-order in which they are written.
-
-@item -U @var{name}
-@findex -U
-Do not predefine @var{name}.
-
-Any @samp{-D} and @samp{-U} options on the command line are processed in
-order, and always before @samp{-imacros @var{file}}, regardless of the
-order in which they are written.
-
-@item -undef
-@findex -undef
-Do not predefine any nonstandard macros.
-
-@item -gcc
-@findex -gcc
-Define the macros @var{__GNUC__}, @var{__GNUC_MINOR__} and
-@var{__GNUC_PATCHLEVEL__}. These are defined automatically when you use
-@samp{gcc -E}; you can turn them off in that case with @samp{-no-gcc}.
-
-@item -A @var{predicate}=@var{answer}
-@findex -A
-Make an assertion with the predicate @var{predicate} and answer
-@var{answer}. This form is preferred to the older form @samp{-A
-@var{predicate}(@var{answer})}, which is still supported, because
-it does not use shell special characters. @xref{Assertions}.
-
-@item -A -@var{predicate}=@var{answer}
-Disable an assertion with the predicate @var{predicate} and answer
-@var{answer}. Specifying no predicate, by @samp{-A-} or @samp{-A -},
-disables all predefined assertions and all assertions preceding it on
-the command line; and also undefines all predefined macros and all
-macros preceding it on the command line.
-
-@item -dM
-@findex -dM
-Instead of outputting the result of preprocessing, output a list of
-@samp{#define} directives for all the macros defined during the
-execution of the preprocessor, including predefined macros. This gives
-you a way of finding out what is predefined in your version of the
-preprocessor; assuming you have no file @samp{foo.h}, the command
+Warn whenever an identifier which is not a macro is encountered in an
+@samp{#if} directive, outside of @samp{defined}. Such identifiers are
+replaced with zero.
-@example
-touch foo.h; cpp -dM foo.h
-@end example
+@item -Werror
+Make all warnings into hard errors. Source code which triggers warnings
+will be rejected.
-@noindent
-will show the values of any predefined macros.
+@item -Wsystem-headers
+Issue warnings for code in system headers. These are normally unhelpful
+in finding bugs in your own code, therefore suppressed. If you are
+responsible for the system library, you may want to see them.
-@item -dD
-@findex -dD
-Like @samp{-dM} except in two respects: it does @emph{not} include the
-predefined macros, and it outputs @emph{both} the @samp{#define}
-directives and the result of preprocessing. Both kinds of output go to
-the standard output file.
+@item -w
+Suppress all warnings, including those which GNU CPP issues by default.
-@item -dN
-@findex -dN
-Like @samp{-dD}, but emit only the macro names, not their expansions.
+@item -pedantic
+Issue all the mandatory diagnostics listed in the C standard. Some of
+them are left out by default, since they trigger frequently on harmless
+code.
-@item -dI
-@findex -dI
-Output @samp{#include} directives in addition to the result of
-preprocessing.
+@item -pedantic-errors
+Issue all the mandatory diagnostics, and make all mandatory diagnostics
+into errors. This includes mandatory diagnostics that GCC issues
+without @samp{-pedantic} but treats as warnings.
@item -M
-@findex -M
Instead of outputting the result of preprocessing, output a rule
suitable for @code{make} describing the dependencies of the main source
file. The preprocessor outputs one @code{make} rule containing the
object file name for that source file, a colon, and the names of all the
-included files, including those coming from @samp{-include} or
-@samp{-imacros} command line options. Unless specified explicitly (with
-@samp{-MT} or @samp{-MQ}), the object file name consists of the basename
-of the source file with any suffix replaced with object file suffix.
-If there are many included files
-then the rule is split into several lines using @samp{\}-newline.
+included files, including those coming from @option{-include} or
+@option{-imacros} command line options.
+
+Unless specified explicitly (with @option{-MT} or @option{-MQ}), the
+object file name consists of the basename of the source file with any
+suffix replaced with object file suffix. If there are many included
+files then the rule is split into several lines using @samp{\}-newline.
+The rule has no commands.
@item -MM
-@findex -MM
-Like @samp{-M}, but mention only the files included with @samp{#include
-"@var{file}"} or with @samp{-include} or @samp{-imacros} command line
+Like @option{-M}, but mention only the files included with @samp{#include
+"@var{file}"} or with @option{-include} or @option{-imacros} command line
options. System header files included with @samp{#include <@var{file}>}
are omitted.
@item -MF @var{file}
-@findex -MF
-When used with @samp{-M} or @samp{-MM}, specifies a file to write the
+When used with @option{-M} or @option{-MM}, specifies a file to write the
dependencies to. This allows the preprocessor to write the preprocessed
-file to stdout normally. If no @samp{-MF} switch is given, CPP sends
+file to stdout normally. If no @option{-MF} switch is given, CPP sends
the rules to stdout and suppresses normal preprocessed output.
@item -MG
-@findex -MG
-When used with @samp{-M} or @samp{-MM}, @samp{-MG} says to treat missing
+When used with @option{-M} or @option{-MM}, @option{-MG} says to treat missing
header files as generated files and assume they live in the same
directory as the source file. It suppresses preprocessed output, as a
missing header file is ordinarily an error.
This feature is used in automatic updating of makefiles.
@item -MP
-@findex -MP
This option instructs CPP to add a phony target for each dependency
other than the main file, causing each to depend on nothing. These
dummy rules work around errors @code{make} gives if you remove header
files without updating the @code{Makefile} to match.
-This is typical output:-
+This is typical output:
-@smallexample
-/tmp/test.o: /tmp/test.c /tmp/test.h
+@example
+test.o: test.c test.h
-/tmp/test.h:
-@end smallexample
+test.h:
+@end example
-@item -MQ @var{target}
@item -MT @var{target}
-@findex -MQ
-@findex -MT
-By default CPP uses the main file name, including any path, and appends
-the object suffix, normally ``.o'', to it to obtain the name of the
-target for dependency generation. With @samp{-MT} you can specify a
-target yourself, overriding the default one.
-If you want multiple targets, you can specify them as a single argument
-to @samp{-MT}, or use multiple @samp{-MT} options.
-
-The targets you specify are output in the order they appear on the
-command line. @samp{-MQ} is identical to @samp{-MT}, except that the
-target name is quoted for Make, but with @samp{-MT} it isn't. For
-example, -MT '$(objpfx)foo.o' gives
-
-@smallexample
-$(objpfx)foo.o: /tmp/foo.c
-@end smallexample
-
-but -MQ '$(objpfx)foo.o' gives
-
-@smallexample
-$$(objpfx)foo.o: /tmp/foo.c
-@end smallexample
-
-The default target is automatically quoted, as if it were given with
-@samp{-MQ}.
-
-@item -H
-@findex -H
-Print the name of each header file used, in addition to other normal
-activities.
+Change the target of the rule emitted by dependency generation. By
+default CPP takes the name of the main input file, including any path,
+deletes any file suffix such as @samp{.c}, and appends the platform's
+usual object suffix. The result is the target.
-@item -imacros @var{file}
-@findex -imacros
-Process @var{file} as input and discard the resulting output.
+An @option{-MT} option will set the target to be exactly the string you
+specify. If you want multiple targets, you can specify them as a single
+argument to @option{-MT}, or use multiple @option{-MT} options.
-This has all the effects of @code{#include "file"} appearing on the
-first line of the main source file, such as generating dependencies and
-being listed with the @samp{-H} option, except that no output is
-generated, and that the first directory searched for @var{file} is the
-preprocessor's working directory @emph{instead of} the directory
-containing the main source file. If not found there, it is searched for
-in the remainder of the @code{#include "..."} search chain as normal.
+For example, @samp{@w{-MT '$(objpfx)foo.o'}} might give
-Because the output is discarded, the main effect of @samp{-imacros
-@var{file}} is to make the macros defined in @var{file} available for
-use in the main input.
+@example
+$(objpfx)foo.o: foo.c
+@end example
-@item -include @var{file}
-@findex -include
-Process @var{file} as input, and include all the resulting output.
+@item -MQ @var{target}
-This has all the effects of @code{#include "file"} appearing on the
-first line of the main source file, such as generating dependencies and
-being listed with the @samp{-H} option, except that the first directory
-searched for @var{file} is the preprocessor's working directory
-@emph{instead of} the directory containing the main source file. If not
-found there, it is searched for in the remainder of the @code{#include
-"..."} search chain as normal.
+Same as @option{-MT}, but it quotes any characters which are special to
+Make. @samp{@w{-MQ '$(objpfx)foo.o'}} gives
-@item -idirafter @var{dir}
-@findex -idirafter
-@cindex second include path
-Add the directory @var{dir} to the second include path, marking it as a
-system directory. The directories on the second include path are searched
-when a header file is not found in any of the directories in the main
-include path (the one that @samp{-I} adds to).
+@example
+$$(objpfx)foo.o: foo.c
+@end example
-@item -iprefix @var{prefix}
-@findex -iprefix
-Specify @var{prefix} as the prefix for subsequent @samp{-iwithprefix}
-options. If the prefix represents a directory, you should include the
-final @samp{/}.
+The default target is automatically quoted, as if it were given with
+@option{-MQ}.
-@item -iwithprefix @var{dir}
-@findex -iwithprefix
-Add a directory to the second include path, marking it as a system
-directory. The directory's name is made by concatenating @var{prefix}
-and @var{dir}, where @var{prefix} was specified previously with
-@samp{-iprefix}.
+@item -MD @var{file}
+@itemx -MMD @var{file}
+@option{-MD @var{file}} is equivalent to @option{-M -MF @var{file}}, and
+@option{-MMD @var{file}} is equivalent to @option{-MM -MF @var{file}}.
-@item -isystem @var{dir}
-@findex -isystem
-Add a directory to the beginning of the second include path, marking it
-as a system directory, so that it gets the same special treatment as
-is applied to the standard system directories. @xref{System Headers}.
+Due to limitations in the compiler driver, you must use these switches
+when you want to generate a dependency file as a side-effect of normal
+compilation.
@item -x c
@itemx -x c++
@itemx -x objective-c
@itemx -x assembler-with-cpp
-@findex -x c
-@findex -x objective-c
-@findex -x assembler-with-cpp
Specify the source language: C, C++, Objective-C, or assembly. This has
nothing to do with standards conformance or extensions; it merely
selects which base syntax to expect. If you give none of these options,
recognize the extension, it will treat the file as C; this is the most
generic mode.
-@strong{Note:} Previous versions of cpp accepted a @samp{-lang} option
+@strong{Note:} Previous versions of cpp accepted a @option{-lang} option
which selected both the language and the standards conformance level.
-This option has been removed, because it conflicts with the @samp{-l}
+This option has been removed, because it conflicts with the @option{-l}
option.
@item -std=@var{standard}
@itemx -ansi
-@findex -std
-@findex -ansi
Specify the standard to which the code should conform. Currently cpp
only knows about the standards for C; other language standards will be
added in the future.
The ISO C standard from 1990. @samp{c89} is the customary shorthand for
this version of the standard.
-The @samp{-ansi} option is equivalent to @samp{-std=c89}.
+The @option{-ansi} option is equivalent to @option{-std=c89}.
@item iso9899:199409
The 1990 C standard, as amended in 1994.
The 1999 C standard plus GNU extensions.
@end table
-@item -ftabstop=NUMBER
-@findex -ftabstop
-Set the distance between tab stops. This helps the preprocessor
-report correct column numbers in warnings or errors, even if tabs appear
-on the line. Values less than 1 or greater than 100 are ignored. The
-default is 8.
+@item -I-
+Split the include path. Any directories specified with @option{-I}
+options before @option{-I-} are searched only for headers requested with
+@samp{@w{#include "@var{file}"}}; they are not searched for
+@samp{@w{#include <@var{file}>}}. If additional directories are
+specified with @option{-I} options after the @option{-I-}, those
+directories are searched for all @samp{#include} directives.
+
+In addition, @option{-I-} inhibits the use of the directory of the current
+file directory as the first search directory for @samp{@w{#include
+"@var{file}"}}. @xref{Search Path}.
+
+@item -nostdinc
+Do not search the standard system directories for header files.
+Only the directories you have specified with @option{-I} options
+(and the directory of the current file, if appropriate) are searched.
+
+@item -nostdinc++
+Do not search for header files in the C++-specific standard directories,
+but do still search the other standard directories. (This option is
+used when building the C++ library.)
+
+@item -include @var{file}
+
+Process @var{file} as if @code{#include "file"} appeared as the first
+line of the primary source file. However, the first directory searched
+for @var{file} is the preprocessor's working directory @emph{instead of}
+the directory containing the main source file. If not found there, it
+is searched for in the remainder of the @code{#include "..."} search
+chain as normal.
+
+If multiple @option{-include} options are given, the files are included
+in the order they appear on the command line.
+
+@item -imacros @var{file}
+
+Exactly like @option{-include}, except that any output produced by
+scanning @var{file} is thrown away. Macros it defines remain defined.
+This allows you to acquire all the macros from a header without also
+processing its declarations.
+
+All files specified by @option{-imacros} are processed before all files
+specified by @option{-include}.
+
+@item -idirafter @var{dir}
+Search @var{dir} for header files, but do it @emph{after} all
+directories specified with @option{-I} and the standard system directories
+have been exhausted. @var{dir} is treated as a system include directory.
+
+@item -iprefix @var{prefix}
+Specify @var{prefix} as the prefix for subsequent @option{-iwithprefix}
+options. If the prefix represents a directory, you should include the
+final @samp{/}.
+
+@item -iwithprefix @var{dir}
+@itemx -iwithprefixbefore @var{dir}
+
+Append @var{dir} to the prefix specified previously with
+@option{-iprefix}, and add the resulting directory to the include search
+path. @option{-iwithprefixbefore} puts it in the same place @option{-I}
+would; @option{-iwithprefix} puts it where @option{-idirafter} would.
+
+Use of these options is discouraged.
+
+@item -isystem @var{dir}
+Search @var{dir} for header files, after all directories specified by
+@option{-I} but before the standard system directories. Mark it
+as a system directory, so that it gets the same special treatment as
+is applied to the standard system directories. @xref{System Headers}.
+
+@item -fpreprocessed
+Indicate to the preprocessor that the input file has already been
+preprocessed. This suppresses things like macro expansion, trigraph
+conversion, escaped newline splicing, and processing of most directives.
+In this mode the integrated preprocessor is little more than a tokenizer
+for the front ends.
+
+@samp{-fpreprocessed} is implicit if the input file has one of the
+extensions @samp{.i}, @samp{.ii} or @samp{.mi}. These are the
+extensions that GCC uses for preprocessed files created by
+@option{-save-temps}.
+
+@item -ftabstop=@var{width}
+Set the distance between tab stops. This helps the preprocessor report
+correct column numbers in warnings or errors, even if tabs appear on the
+line. If the value is less than 1 or greater than 100, the option is
+ignored. The default is 8.
+
+@item -fno-show-column
+Do not print column numbers in diagnostics. This may be necessary if
+diagnostics are being scanned by a program that does not understand the
+column numbers, such as @code{dejagnu}.
+
+@item -A @var{predicate}=@var{answer}
+Make an assertion with the predicate @var{predicate} and answer
+@var{answer}. This form is preferred to the older form @option{-A
+@var{predicate}(@var{answer})}, which is still supported, because
+it does not use shell special characters. @xref{Assertions}.
+
+@item -A -@var{predicate}=@var{answer}
+Cancel an assertion with the predicate @var{predicate} and answer
+@var{answer}.
+
+@item -A-
+Cancel all predefined assertions and all assertions preceding it on
+the command line. Also, undefine all predefined macros and all
+macros preceding it on the command line. (This is a historical wart and
+may change in the future.)
+
+@item -dM
+Instead of the normal output, generate a list of @samp{#define}
+directives for all the macros defined during the execution of the
+preprocessor, including predefined macros. This gives you a way of
+finding out what is predefined in your version of the preprocessor.
+Assuming you have no file @samp{foo.h}, the command
+
+@example
+touch foo.h; cpp -dM foo.h
+@end example
+
+@noindent
+will show all the predefined macros.
+
+@item -dD
+Like @option{-dM} except in two respects: it does @emph{not} include the
+predefined macros, and it outputs @emph{both} the @samp{#define}
+directives and the result of preprocessing. Both kinds of output go to
+the standard output file.
+
+@item -dN
+Like @option{-dD}, but emit only the macro names, not their expansions.
+
+@item -dI
+Output @samp{#include} directives in addition to the result of
+preprocessing.
+
+@item -P
+Inhibit generation of linemarkers in the output from the preprocessor.
+This might be useful when running the preprocessor on something that is
+not C code, and will be sent to a program which might be confused by the
+linemarkers. @xref{Preprocessor Output}.
+
+@item -C
+Do not discard comments. All comments are passed through to the output
+file, except for comments in processed directives, which are deleted
+along with the directive. Comments appearing in the expansion list of a
+macro will be preserved, and appear in place wherever the macro is
+invoked.
+
+You should be prepared for side effects when using @option{-C}; it causes
+the preprocessor to treat comments as tokens in their own right. For
+example, macro redefinitions that were trivial when comments were
+replaced by a single space might become significant when comments are
+retained. Also, comments appearing at the start of what would be a
+directive line have the effect of turning that line into an ordinary
+source line, since the first token on the line is no longer a @samp{#}.
+
+@item -gcc
+Define the macros @sc{__gnuc__}, @sc{__gnuc_minor__} and
+@sc{__gnuc_patchlevel__}. These are defined automatically when you use
+@samp{gcc -E}; you can turn them off in that case with @option{-no-gcc}.
+
+@item -traditional
+Try to imitate the behavior of old-fashioned C, as opposed to ISO
+C@. @xref{Traditional Mode}.
+
+@item -trigraphs
+Process trigraph sequences. @xref{Initial processing}.
+
+@item -remap
+Enable special code to work around file systems which only permit very
+short file names, such as MS-DOS.
@item -$
-@findex -$
Forbid the use of @samp{$} in identifiers. The C standard allows
implementations to define extra characters that can appear in
identifiers. By default the GNU C preprocessor permits @samp{$}, a
common extension.
+
+@item -h
+@itemx --help
+@itemx --target-help
+Print text describing all the command line options instead of
+preprocessing anything.
+
+@item -v
+Verbose mode. Print out GNU CPP's version number at the beginning of
+execution, and report the final form of the include path.
+
+@item -H
+Print the name of each header file used, in addition to other normal
+activities. Each name is indented to show how deep in the
+@samp{#include} stack it is.
+
+@item -version
+@itemx --version
+Print out GNU CPP's version number. With one dash, proceed to
+preprocess as normal. With two dashes, exit immediately.
@end table
@c man end
-@node Concept Index, Index, Invocation, Top
+@page
+@node Index of Directives
+@unnumbered Index of Directives
+@printindex fn
+
+@node Concept Index
@unnumbered Concept Index
@printindex cp
-@node Index,, Concept Index, Top
-@unnumbered Index of Directives, Macros and Options
-@printindex fn
-
@bye
projects / gcc.git / commitdiff