home *** CD-ROM | disk | FTP | other *** search
/ Whiteline: Alpha / Whiteline Alpha.iso / progtool / c / gcc / gcc258s.zoo / cpp.info-2 < prev    next >
Encoding:
GNU Info File  |  1993-10-16  |  48.6 KB  |  1,242 lines
  1. This is Info file cpp.info, produced by Makeinfo-1.54 from the input
  2. file cpp.texi.
  3.  
  4.    This file documents the GNU C Preprocessor.
  5.  
  6.    Copyright 1987, 1989, 1991, 1992, 1993 Free Software Foundation, Inc.
  7.  
  8.    Permission is granted to make and distribute verbatim copies of this
  9. manual provided the copyright notice and this permission notice are
  10. preserved on all copies.
  11.  
  12.    Permission is granted to copy and distribute modified versions of
  13. this manual under the conditions for verbatim copying, provided also
  14. that the entire resulting derived work is distributed under the terms
  15. of a permission notice identical to this one.
  16.  
  17.    Permission is granted to copy and distribute translations of this
  18. manual into another language, under the above conditions for modified
  19. versions.
  20.  
  22. File: cpp.info,  Node: Swallow Semicolon,  Next: Side Effects,  Prev: Macro Parentheses,  Up: Macro Pitfalls
  23.  
  24. Swallowing the Semicolon
  25. ........................
  26.  
  27.    Often it is desirable to define a macro that expands into a compound
  28. statement.  Consider, for example, the following macro, that advances a
  29. pointer (the argument `p' says where to find it) across whitespace
  30. characters:
  31.  
  32.      #define SKIP_SPACES (p, limit)  \
  33.      { register char *lim = (limit); \
  34.        while (p != lim) {            \
  35.          if (*p++ != ' ') {          \
  36.            p--; break; }}}
  37.  
  38. Here Backslash-Newline is used to split the macro definition, which must
  39. be a single line, so that it resembles the way such C code would be
  40. laid out if not part of a macro definition.
  41.  
  42.    A call to this macro might be `SKIP_SPACES (p, lim)'.  Strictly
  43. speaking, the call expands to a compound statement, which is a complete
  44. statement with no need for a semicolon to end it.  But it looks like a
  45. function call.  So it minimizes confusion if you can use it like a
  46. function call, writing a semicolon afterward, as in `SKIP_SPACES (p,
  47. lim);'
  48.  
  49.    But this can cause trouble before `else' statements, because the
  50. semicolon is actually a null statement.  Suppose you write
  51.  
  52.      if (*p != 0)
  53.        SKIP_SPACES (p, lim);
  54.      else ...
  55.  
  56. The presence of two statements--the compound statement and a null
  57. statement--in between the `if' condition and the `else' makes invalid C
  58. code.
  59.  
  60.    The definition of the macro `SKIP_SPACES' can be altered to solve
  61. this problem, using a `do ... while' statement.  Here is how:
  62.  
  63.      #define SKIP_SPACES (p, limit)     \
  64.      do { register char *lim = (limit); \
  65.           while (p != lim) {            \
  66.             if (*p++ != ' ') {          \
  67.               p--; break; }}}           \
  68.      while (0)
  69.  
  70.    Now `SKIP_SPACES (p, lim);' expands into
  71.  
  72.      do {...} while (0);
  73.  
  74. which is one statement.
  75.  
  77. File: cpp.info,  Node: Side Effects,  Next: Self-Reference,  Prev: Swallow Semicolon,  Up: Macro Pitfalls
  78.  
  79. Duplication of Side Effects
  80. ...........................
  81.  
  82.    Many C programs define a macro `min', for "minimum", like this:
  83.  
  84.      #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
  85.  
  86.    When you use this macro with an argument containing a side effect,
  87. as shown here,
  88.  
  89.      next = min (x + y, foo (z));
  90.  
  91. it expands as follows:
  92.  
  93.      next = ((x + y) < (foo (z)) ? (x + y) : (foo (z)));
  94.  
  95. where `x + y' has been substituted for `X' and `foo (z)' for `Y'.
  96.  
  97.    The function `foo' is used only once in the statement as it appears
  98. in the program, but the expression `foo (z)' has been substituted twice
  99. into the macro expansion.  As a result, `foo' might be called two times
  100. when the statement is executed.  If it has side effects or if it takes
  101. a long time to compute, the results might not be what you intended.  We
  102. say that `min' is an "unsafe" macro.
  103.  
  104.    The best solution to this problem is to define `min' in a way that
  105. computes the value of `foo (z)' only once.  The C language offers no
  106. standard way to do this, but it can be done with GNU C extensions as
  107. follows:
  108.  
  109.      #define min(X, Y)                     \
  110.      ({ typeof (X) __x = (X), __y = (Y);   \
  111.         (__x < __y) ? __x : __y; })
  112.  
  113.    If you do not wish to use GNU C extensions, the only solution is to
  114. be careful when *using* the macro `min'.  For example, you can
  115. calculate the value of `foo (z)', save it in a variable, and use that
  116. variable in `min':
  117.  
  118.      #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
  119.      ...
  120.      {
  121.        int tem = foo (z);
  122.        next = min (x + y, tem);
  123.      }
  124.  
  125. (where we assume that `foo' returns type `int').
  126.  
  128. File: cpp.info,  Node: Self-Reference,  Next: Argument Prescan,  Prev: Side Effects,  Up: Macro Pitfalls
  129.  
  130. Self-Referential Macros
  131. .......................
  132.  
  133.    A "self-referential" macro is one whose name appears in its
  134. definition.  A special feature of ANSI Standard C is that the
  135. self-reference is not considered a macro call.  It is passed into the
  136. preprocessor output unchanged.
  137.  
  138.    Let's consider an example:
  139.  
  140.      #define foo (4 + foo)
  141.  
  142. where `foo' is also a variable in your program.
  143.  
  144.    Following the ordinary rules, each reference to `foo' will expand
  145. into `(4 + foo)'; then this will be rescanned and will expand into `(4
  146. + (4 + foo))'; and so on until it causes a fatal error (memory full) in
  147. the preprocessor.
  148.  
  149.    However, the special rule about self-reference cuts this process
  150. short after one step, at `(4 + foo)'.  Therefore, this macro definition
  151. has the possibly useful effect of causing the program to add 4 to the
  152. value of `foo' wherever `foo' is referred to.
  153.  
  154.    In most cases, it is a bad idea to take advantage of this feature.  A
  155. person reading the program who sees that `foo' is a variable will not
  156. expect that it is a macro as well.  The reader will come across the
  157. identifier `foo' in the program and think its value should be that of
  158. the variable `foo', whereas in fact the value is four greater.
  159.  
  160.    The special rule for self-reference applies also to "indirect"
  161. self-reference.  This is the case where a macro X expands to use a
  162. macro `y', and the expansion of `y' refers to the macro `x'.  The
  163. resulting reference to `x' comes indirectly from the expansion of `x',
  164. so it is a self-reference and is not further expanded.  Thus, after
  165.  
  166.      #define x (4 + y)
  167.      #define y (2 * x)
  168.  
  169. `x' would expand into `(4 + (2 * x))'.  Clear?
  170.  
  171.    But suppose `y' is used elsewhere, not from the definition of `x'.
  172. Then the use of `x' in the expansion of `y' is not a self-reference
  173. because `x' is not "in progress".  So it does expand.  However, the
  174. expansion of `x' contains a reference to `y', and that is an indirect
  175. self-reference now because `y' is "in progress".  The result is that
  176. `y' expands to `(2 * (4 + y))'.
  177.  
  178.    It is not clear that this behavior would ever be useful, but it is
  179. specified by the ANSI C standard, so you may need to understand it.
  180.  
  182. File: cpp.info,  Node: Argument Prescan,  Next: Cascaded Macros,  Prev: Self-Reference,  Up: Macro Pitfalls
  183.  
  184. Separate Expansion of Macro Arguments
  185. .....................................
  186.  
  187.    We have explained that the expansion of a macro, including the
  188. substituted actual arguments, is scanned over again for macro calls to
  189. be expanded.
  190.  
  191.    What really happens is more subtle: first each actual argument text
  192. is scanned separately for macro calls.  Then the results of this are
  193. substituted into the macro body to produce the macro expansion, and the
  194. macro expansion is scanned again for macros to expand.
  195.  
  196.    The result is that the actual arguments are scanned *twice* to expand
  197. macro calls in them.
  198.  
  199.    Most of the time, this has no effect.  If the actual argument
  200. contained any macro calls, they are expanded during the first scan.
  201. The result therefore contains no macro calls, so the second scan does
  202. not change it.  If the actual argument were substituted as given, with
  203. no prescan, the single remaining scan would find the same macro calls
  204. and produce the same results.
  205.  
  206.    You might expect the double scan to change the results when a
  207. self-referential macro is used in an actual argument of another macro
  208. (*note Self-Reference::.): the self-referential macro would be expanded
  209. once in the first scan, and a second time in the second scan.  But this
  210. is not what happens.  The self-references that do not expand in the
  211. first scan are marked so that they will not expand in the second scan
  212. either.
  213.  
  214.    The prescan is not done when an argument is stringified or
  215. concatenated.  Thus,
  216.  
  217.      #define str(s) #s
  218.      #define foo 4
  219.      str (foo)
  220.  
  221. expands to `"foo"'.  Once more, prescan has been prevented from having
  222. any noticeable effect.
  223.  
  224.    More precisely, stringification and concatenation use the argument as
  225. written, in un-prescanned form.  The same actual argument would be used
  226. in prescanned form if it is substituted elsewhere without
  227. stringification or concatenation.
  228.  
  229.      #define str(s) #s lose(s)
  230.      #define foo 4
  231.      str (foo)
  232.  
  233.    expands to `"foo" lose(4)'.
  234.  
  235.    You might now ask, "Why mention the prescan, if it makes no
  236. difference?  And why not skip it and make the preprocessor faster?"
  237. The answer is that the prescan does make a difference in three special
  238. cases:
  239.  
  240.    * Nested calls to a macro.
  241.  
  242.    * Macros that call other macros that stringify or concatenate.
  243.  
  244.    * Macros whose expansions contain unshielded commas.
  245.  
  246.    We say that "nested" calls to a macro occur when a macro's actual
  247. argument contains a call to that very macro.  For example, if `f' is a
  248. macro that expects one argument, `f (f (1))' is a nested pair of calls
  249. to `f'.  The desired expansion is made by expanding `f (1)' and
  250. substituting that into the definition of `f'.  The prescan causes the
  251. expected result to happen.  Without the prescan, `f (1)' itself would
  252. be substituted as an actual argument, and the inner use of `f' would
  253. appear during the main scan as an indirect self-reference and would not
  254. be expanded.  Here, the prescan cancels an undesirable side effect (in
  255. the medical, not computational, sense of the term) of the special rule
  256. for self-referential macros.
  257.  
  258.    But prescan causes trouble in certain other cases of nested macro
  259. calls.  Here is an example:
  260.  
  261.      #define foo  a,b
  262.      #define bar(x) lose(x)
  263.      #define lose(x) (1 + (x))
  264.      
  265.      bar(foo)
  266.  
  267. We would like `bar(foo)' to turn into `(1 + (foo))', which would then
  268. turn into `(1 + (a,b))'.  But instead, `bar(foo)' expands into
  269. `lose(a,b)', and you get an error because `lose' requires a single
  270. argument.  In this case, the problem is easily solved by the same
  271. parentheses that ought to be used to prevent misnesting of arithmetic
  272. operations:
  273.  
  274.      #define foo (a,b)
  275.      #define bar(x) lose((x))
  276.  
  277.    The problem is more serious when the operands of the macro are not
  278. expressions; for example, when they are statements.  Then parentheses
  279. are unacceptable because they would make for invalid C code:
  280.  
  281.      #define foo { int a, b; ... }
  282.  
  283. In GNU C you can shield the commas using the `({...})' construct which
  284. turns a compound statement into an expression:
  285.  
  286.      #define foo ({ int a, b; ... })
  287.  
  288.    Or you can rewrite the macro definition to avoid such commas:
  289.  
  290.      #define foo { int a; int b; ... }
  291.  
  292.    There is also one case where prescan is useful.  It is possible to
  293. use prescan to expand an argument and then stringify it--if you use two
  294. levels of macros.  Let's add a new macro `xstr' to the example shown
  295. above:
  296.  
  297.      #define xstr(s) str(s)
  298.      #define str(s) #s
  299.      #define foo 4
  300.      xstr (foo)
  301.  
  302.    This expands into `"4"', not `"foo"'.  The reason for the difference
  303. is that the argument of `xstr' is expanded at prescan (because `xstr'
  304. does not specify stringification or concatenation of the argument).
  305. The result of prescan then forms the actual argument for `str'.  `str'
  306. uses its argument without prescan because it performs stringification;
  307. but it cannot prevent or undo the prescanning already done by `xstr'.
  308.  
  310. File: cpp.info,  Node: Cascaded Macros,  Next: Newlines in Args,  Prev: Argument Prescan,  Up: Macro Pitfalls
  311.  
  312. Cascaded Use of Macros
  313. ......................
  314.  
  315.    A "cascade" of macros is when one macro's body contains a reference
  316. to another macro.  This is very common practice.  For example,
  317.  
  318.      #define BUFSIZE 1020
  319.      #define TABLESIZE BUFSIZE
  320.  
  321.    This is not at all the same as defining `TABLESIZE' to be `1020'.
  322. The `#define' for `TABLESIZE' uses exactly the body you specify--in
  323. this case, `BUFSIZE'--and does not check to see whether it too is the
  324. name of a macro.
  325.  
  326.    It's only when you *use* `TABLESIZE' that the result of its expansion
  327. is checked for more macro names.
  328.  
  329.    This makes a difference if you change the definition of `BUFSIZE' at
  330. some point in the source file.  `TABLESIZE', defined as shown, will
  331. always expand using the definition of `BUFSIZE' that is currently in
  332. effect:
  333.  
  334.      #define BUFSIZE 1020
  335.      #define TABLESIZE BUFSIZE
  336.      #undef BUFSIZE
  337.      #define BUFSIZE 37
  338.  
  339. Now `TABLESIZE' expands (in two stages) to `37'.
  340.  
  342. File: cpp.info,  Node: Newlines in Args,  Prev: Cascaded Macros,  Up: Macro Pitfalls
  343.  
  344. Newlines in Macro Arguments
  345. ---------------------------
  346.  
  347.    Traditional macro processing carries forward all newlines in macro
  348. arguments into the expansion of the macro.  This means that, if some of
  349. the arguments are substituted more than once, or not at all, or out of
  350. order, newlines can be duplicated, lost, or moved around within the
  351. expansion.  If the expansion consists of multiple statements, then the
  352. effect is to distort the line numbers of some of these statements.  The
  353. result can be incorrect line numbers, in error messages or displayed in
  354. a debugger.
  355.  
  356.    The GNU C preprocessor operating in ANSI C mode adjusts appropriately
  357. for multiple use of an argument--the first use expands all the
  358. newlines, and subsequent uses of the same argument produce no newlines.
  359. But even in this mode, it can produce incorrect line numbering if
  360. arguments are used out of order, or not used at all.
  361.  
  362.    Here is an example illustrating this problem:
  363.  
  364.      #define ignore_second_arg(a,b,c) a; c
  365.      
  366.      ignore_second_arg (foo (),
  367.                         ignored (),
  368.                         syntax error);
  369.  
  370. The syntax error triggered by the tokens `syntax error' results in an
  371. error message citing line four, even though the statement text comes
  372. from line five.
  373.  
  375. File: cpp.info,  Node: Conditionals,  Next: Combining Sources,  Prev: Macros,  Up: Top
  376.  
  377. Conditionals
  378. ============
  379.  
  380.    In a macro processor, a "conditional" is a command that allows a part
  381. of the program to be ignored during compilation, on some conditions.
  382. In the C preprocessor, a conditional can test either an arithmetic
  383. expression or whether a name is defined as a macro.
  384.  
  385.    A conditional in the C preprocessor resembles in some ways an `if'
  386. statement in C, but it is important to understand the difference between
  387. them.  The condition in an `if' statement is tested during the execution
  388. of your program.  Its purpose is to allow your program to behave
  389. differently from run to run, depending on the data it is operating on.
  390. The condition in a preprocessor conditional command is tested when your
  391. program is compiled.  Its purpose is to allow different code to be
  392. included in the program depending on the situation at the time of
  393. compilation.
  394.  
  395. * Menu:
  396.  
  397. * Uses: Conditional Uses.       What conditionals are for.
  398. * Syntax: Conditional Syntax.   How conditionals are written.
  399. * Deletion: Deleted Code.       Making code into a comment.
  400. * Macros: Conditionals-Macros.  Why conditionals are used with macros.
  401. * Assertions::                How and why to use assertions.
  402. * Errors: #error Command.       Detecting inconsistent compilation parameters.
  403.  
  405. File: cpp.info,  Node: Conditional Uses,  Next: Conditional Syntax,  Up: Conditionals
  406.  
  407. Why Conditionals are Used
  408. -------------------------
  409.  
  410.    Generally there are three kinds of reason to use a conditional.
  411.  
  412.    * A program may need to use different code depending on the machine
  413.      or operating system it is to run on.  In some cases the code for
  414.      one operating system may be erroneous on another operating system;
  415.      for example, it might refer to library routines that do not exist
  416.      on the other system.  When this happens, it is not enough to avoid
  417.      executing the invalid code: merely having it in the program makes
  418.      it impossible to link the program and run it.  With a preprocessor
  419.      conditional, the offending code can be effectively excised from
  420.      the program when it is not valid.
  421.  
  422.    * You may want to be able to compile the same source file into two
  423.      different programs.  Sometimes the difference between the programs
  424.      is that one makes frequent time-consuming consistency checks on its
  425.      intermediate data while the other does not.
  426.  
  427.    * A conditional whose condition is always false is a good way to
  428.      exclude code from the program but keep it as a sort of comment for
  429.      future reference.
  430.  
  431.    Most simple programs that are intended to run on only one machine
  432. will not need to use preprocessor conditionals.
  433.  
  435. File: cpp.info,  Node: Conditional Syntax,  Next: Deleted Code,  Prev: Conditional Uses,  Up: Conditionals
  436.  
  437. Syntax of Conditionals
  438. ----------------------
  439.  
  440.    A conditional in the C preprocessor begins with a "conditional
  441. command": `#if', `#ifdef' or `#ifndef'.  *Note Conditionals-Macros::,
  442. for information on `#ifdef' and `#ifndef'; only `#if' is explained here.
  443.  
  444. * Menu:
  445.  
  446. * If: #if Command.     Basic conditionals using `#if' and `#endif'.
  447. * Else: #else Command. Including some text if the condition fails.
  448. * Elif: #elif Command. Testing several alternative possibilities.
  449.  
  451. File: cpp.info,  Node: #if Command,  Next: #else Command,  Up: Conditional Syntax
  452.  
  453. The `#if' Command
  454. .................
  455.  
  456.    The `#if' command in its simplest form consists of
  457.  
  458.      #if EXPRESSION
  459.      CONTROLLED TEXT
  460.      #endif /* EXPRESSION */
  461.  
  462.    The comment following the `#endif' is not required, but it is a good
  463. practice because it helps people match the `#endif' to the
  464. corresponding `#if'.  Such comments should always be used, except in
  465. short conditionals that are not nested.  In fact, you can put anything
  466. at all after the `#endif' and it will be ignored by the GNU C
  467. preprocessor, but only comments are acceptable in ANSI Standard C.
  468.  
  469.    EXPRESSION is a C expression of integer type, subject to stringent
  470. restrictions.  It may contain
  471.  
  472.    * Integer constants, which are all regarded as `long' or `unsigned
  473.      long'.
  474.  
  475.    * Character constants, which are interpreted according to the
  476.      character set and conventions of the machine and operating system
  477.      on which the preprocessor is running.  The GNU C preprocessor uses
  478.      the C data type `char' for these character constants; therefore,
  479.      whether some character codes are negative is determined by the C
  480.      compiler used to compile the preprocessor.  If it treats `char' as
  481.      signed, then character codes large enough to set the sign bit will
  482.      be considered negative; otherwise, no character code is considered
  483.      negative.
  484.  
  485.    * Arithmetic operators for addition, subtraction, multiplication,
  486.      division, bitwise operations, shifts, comparisons, and `&&' and
  487.      `||'.
  488.  
  489.    * Identifiers that are not macros, which are all treated as zero(!).
  490.  
  491.    * Macro calls.  All macro calls in the expression are expanded before
  492.      actual computation of the expression's value begins.
  493.  
  494.    Note that `sizeof' operators and `enum'-type values are not allowed.
  495. `enum'-type values, like all other identifiers that are not taken as
  496. macro calls and expanded, are treated as zero.
  497.  
  498.    The CONTROLLED TEXT inside of a conditional can include preprocessor
  499. commands.  Then the commands inside the conditional are obeyed only if
  500. that branch of the conditional succeeds.  The text can also contain
  501. other conditional groups.  However, the `#if' and `#endif' commands
  502. must balance.
  503.  
  505. File: cpp.info,  Node: #else Command,  Next: #elif Command,  Prev: #if Command,  Up: Conditional Syntax
  506.  
  507. The `#else' Command
  508. ...................
  509.  
  510.    The `#else' command can be added to a conditional to provide
  511. alternative text to be used if the condition is false.  This is what it
  512. looks like:
  513.  
  514.      #if EXPRESSION
  515.      TEXT-IF-TRUE
  516.      #else /* Not EXPRESSION */
  517.      TEXT-IF-FALSE
  518.      #endif /* Not EXPRESSION */
  519.  
  520.    If EXPRESSION is nonzero, and thus the TEXT-IF-TRUE is active, then
  521. `#else' acts like a failing conditional and the TEXT-IF-FALSE is
  522. ignored.  Contrariwise, if the `#if' conditional fails, the
  523. TEXT-IF-FALSE is considered included.
  524.  
  526. File: cpp.info,  Node: #elif Command,  Prev: #else Command,  Up: Conditional Syntax
  527.  
  528. The `#elif' Command
  529. ...................
  530.  
  531.    One common case of nested conditionals is used to check for more
  532. than two possible alternatives.  For example, you might have
  533.  
  534.      #if X == 1
  535.      ...
  536.      #else /* X != 1 */
  537.      #if X == 2
  538.      ...
  539.      #else /* X != 2 */
  540.      ...
  541.      #endif /* X != 2 */
  542.      #endif /* X != 1 */
  543.  
  544.    Another conditional command, `#elif', allows this to be abbreviated
  545. as follows:
  546.  
  547.      #if X == 1
  548.      ...
  549.      #elif X == 2
  550.      ...
  551.      #else /* X != 2 and X != 1*/
  552.      ...
  553.      #endif /* X != 2 and X != 1*/
  554.  
  555.    `#elif' stands for "else if".  Like `#else', it goes in the middle
  556. of a `#if'-`#endif' pair and subdivides it; it does not require a
  557. matching `#endif' of its own.  Like `#if', the `#elif' command includes
  558. an expression to be tested.
  559.  
  560.    The text following the `#elif' is processed only if the original
  561. `#if'-condition failed and the `#elif' condition succeeds.  More than
  562. one `#elif' can go in the same `#if'-`#endif' group.  Then the text
  563. after each `#elif' is processed only if the `#elif' condition succeeds
  564. after the original `#if' and any previous `#elif' commands within it
  565. have failed.  `#else' is equivalent to `#elif 1', and `#else' is
  566. allowed after any number of `#elif' commands, but `#elif' may not follow
  567. `#else'.
  568.  
  570. File: cpp.info,  Node: Deleted Code,  Next: Conditionals-Macros,  Prev: Conditional Syntax,  Up: Conditionals
  571.  
  572. Keeping Deleted Code for Future Reference
  573. -----------------------------------------
  574.  
  575.    If you replace or delete a part of the program but want to keep the
  576. old code around as a comment for future reference, the easy way to do
  577. this is to put `#if 0' before it and `#endif' after it.
  578.  
  579.    This works even if the code being turned off contains conditionals,
  580. but they must be entire conditionals (balanced `#if' and `#endif').
  581.  
  583. File: cpp.info,  Node: Conditionals-Macros,  Next: Assertions,  Prev: Deleted Code,  Up: Conditionals
  584.  
  585. Conditionals and Macros
  586. -----------------------
  587.  
  588.    Conditionals are useful in connection with macros or assertions,
  589. because those are the only ways that an expression's value can vary
  590. from one compilation to another.  A `#if' command whose expression uses
  591. no macros or assertions is equivalent to `#if 1' or `#if 0'; you might
  592. as well determine which one, by computing the value of the expression
  593. yourself, and then simplify the program.
  594.  
  595.    For example, here is a conditional that tests the expression
  596. `BUFSIZE == 1020', where `BUFSIZE' must be a macro.
  597.  
  598.      #if BUFSIZE == 1020
  599.        printf ("Large buffers!\n");
  600.      #endif /* BUFSIZE is large */
  601.  
  602.    (Programmers often wish they could test the size of a variable or
  603. data type in `#if', but this does not work.  The preprocessor does not
  604. understand `sizeof', or typedef names, or even the type keywords such
  605. as `int'.)
  606.  
  607.    The special operator `defined' is used in `#if' expressions to test
  608. whether a certain name is defined as a macro.  Either `defined NAME' or
  609. `defined (NAME)' is an expression whose value is 1 if NAME is defined
  610. as macro at the current point in the program, and 0 otherwise.  For the
  611. `defined' operator it makes no difference what the definition of the
  612. macro is; all that matters is whether there is a definition.  Thus, for
  613. example,
  614.  
  615.      #if defined (vax) || defined (ns16000)
  616.  
  617. would include the following code if either of the names `vax' and
  618. `ns16000' is defined as a macro.  You can test the same condition using
  619. assertions (*note Assertions::.), like this:
  620.  
  621.      #if #cpu (vax) || #cpu (ns16000)
  622.  
  623.    If a macro is defined and later undefined with `#undef', subsequent
  624. use of the `defined' operator returns 0, because the name is no longer
  625. defined.  If the macro is defined again with another `#define',
  626. `defined' will recommence returning 1.
  627.  
  628.    Conditionals that test just the definedness of one name are very
  629. common, so there are two special short conditional commands for this
  630. case.
  631.  
  632. `#ifdef NAME'
  633.      is equivalent to `#if defined (NAME)'.
  634.  
  635. `#ifndef NAME'
  636.      is equivalent to `#if ! defined (NAME)'.
  637.  
  638.    Macro definitions can vary between compilations for several reasons.
  639.  
  640.    * Some macros are predefined on each kind of machine.  For example,
  641.      on a Vax, the name `vax' is a predefined macro.  On other
  642.      machines, it would not be defined.
  643.  
  644.    * Many more macros are defined by system header files.  Different
  645.      systems and machines define different macros, or give them
  646.      different values.  It is useful to test these macros with
  647.      conditionals to avoid using a system feature on a machine where it
  648.      is not implemented.
  649.  
  650.    * Macros are a common way of allowing users to customize a program
  651.      for different machines or applications.  For example, the macro
  652.      `BUFSIZE' might be defined in a configuration file for your
  653.      program that is included as a header file in each source file.  You
  654.      would use `BUFSIZE' in a preprocessor conditional in order to
  655.      generate different code depending on the chosen configuration.
  656.  
  657.    * Macros can be defined or undefined with `-D' and `-U' command
  658.      options when you compile the program.  You can arrange to compile
  659.      the same source file into two different programs by choosing a
  660.      macro name to specify which program you want, writing conditionals
  661.      to test whether or how this macro is defined, and then controlling
  662.      the state of the macro with compiler command options.  *Note
  663.      Invocation::.
  664.  
  665.    Assertions are usually predefined, but can be defined with
  666. preprocessor commands or command-line options.
  667.  
  669. File: cpp.info,  Node: Assertions,  Next: #error Command,  Prev: Conditionals-Macros,  Up: Conditionals
  670.  
  671. Assertions
  672. ----------
  673.  
  674.    "Assertions" are a more systematic alternative to macros in writing
  675. conditionals to test what sort of computer or system the compiled
  676. program will run on.  Assertions are usually predefined, but you can
  677. define them with preprocessor commands or command-line options.
  678.  
  679.    The macros traditionally used to describe the type of target are not
  680. classified in any way according to which question they answer; they may
  681. indicate a hardware architecture, a particular hardware model, an
  682. operating system, a particular version of an operating system, or
  683. specific configuration options.  These are jumbled together in a single
  684. namespace.  In contrast, each assertion consists of a named question and
  685. an answer.  The question is usually called the "predicate".  An
  686. assertion looks like this:
  687.  
  688.      #PREDICATE (ANSWER)
  689.  
  690. You must use a properly formed identifier for PREDICATE.  The value of
  691. ANSWER can be any sequence of words; all characters are significant
  692. except for leading and trailing whitespace, and differences in internal
  693. whitespace sequences are ignored.  Thus, `x + y' is different from
  694. `x+y' but equivalent to `x + y'.  `)' is not allowed in an answer.
  695.  
  696.    Here is a conditional to test whether the answer ANSWER is asserted
  697. for the predicate PREDICATE:
  698.  
  699.      #if #PREDICATE (ANSWER)
  700.  
  701. There may be more than one answer asserted for a given predicate.  If
  702. you omit the answer, you can test whether *any* answer is asserted for
  703. PREDICATE:
  704.  
  705.      #if #PREDICATE
  706.  
  707.    Most of the time, the assertions you test will be predefined
  708. assertions.  GNU C provides three predefined predicates: `system',
  709. `cpu', and `machine'.  `system' is for assertions about the type of
  710. software, `cpu' describes the type of computer architecture, and
  711. `machine' gives more information about the computer.  For example, on a
  712. GNU system, the following assertions would be true:
  713.  
  714.      #system (gnu)
  715.      #system (mach)
  716.      #system (mach 3)
  717.      #system (mach 3.SUBVERSION)
  718.      #system (hurd)
  719.      #system (hurd VERSION)
  720.  
  721. and perhaps others.  The alternatives with more or less version
  722. information let you ask more or less detailed questions about the type
  723. of system software.
  724.  
  725.    On a Unix system, you would find `#system (unix)' and perhaps one of:
  726. `#system (aix)', `#system (bsd)', `#system (hpux)', `#system (lynx)',
  727. `#system (mach)', `#system (posix)', `#system (svr3)', `#system
  728. (svr4)', or `#system (xpg4)' with possible version numbers following.
  729.  
  730.    Other values for `system' are `#system (mvs)' and `#system (vms)'.
  731.  
  732.    *Portability note:* Many Unix C compilers provide only one answer
  733. for the `system' assertion: `#system (unix)', if they support
  734. assertions at all.  This is less than useful.
  735.  
  736.    An assertion with a multi-word answer is completely different from
  737. several assertions with individual single-word answers.  For example,
  738. the presence of `system (mach 3.0)' does not mean that `system (3.0)'
  739. is true.  It also does not directly imply `system (mach)', but in GNU
  740. C, that last will normally be asserted as well.
  741.  
  742.    The current list of possible assertion values for `cpu' is: `#cpu
  743. (a29k)', `#cpu (alpha)', `#cpu (arm)', `#cpu (clipper)', `#cpu
  744. (convex)', `#cpu (elxsi)', `#cpu (tron)', `#cpu (h8300)', `#cpu
  745. (i370)', `#cpu (i386)', `#cpu (i860)', `#cpu (i960)', `#cpu (m68k)',
  746. `#cpu (m88k)', `#cpu (mips)', `#cpu (ns32k)', `#cpu (hppa)', `#cpu
  747. (pyr)', `#cpu (ibm032)', `#cpu (rs6000)', `#cpu (sh)', `#cpu (sparc)',
  748. `#cpu (spur)', `#cpu (tahoe)', `#cpu (vax)', `#cpu (we32000)'.
  749.  
  750.    You can create assertions within a C program using `#assert', like
  751. this:
  752.  
  753.      #assert PREDICATE (ANSWER)
  754.  
  755. (Note the absence of a `#' before PREDICATE.)
  756.  
  757.    Each time you do this, you assert a new true answer for PREDICATE.
  758. Asserting one answer does not invalidate previously asserted answers;
  759. they all remain true.  The only way to remove an assertion is with
  760. `#unassert'.  `#unassert' has the same syntax as `#assert'.  You can
  761. also remove all assertions about PREDICATE like this:
  762.  
  763.      #unassert PREDICATE
  764.  
  765.    You can also add or cancel assertions using command options when you
  766. run `gcc' or `cpp'.  *Note Invocation::.
  767.  
  769. File: cpp.info,  Node: #error Command,  Prev: Assertions,  Up: Conditionals
  770.  
  771. The `#error' and `#warning' Commands
  772. ------------------------------------
  773.  
  774.    The command `#error' causes the preprocessor to report a fatal
  775. error.  The rest of the line that follows `#error' is used as the error
  776. message.
  777.  
  778.    You would use `#error' inside of a conditional that detects a
  779. combination of parameters which you know the program does not properly
  780. support.  For example, if you know that the program will not run
  781. properly on a Vax, you might write
  782.  
  783.      #ifdef vax
  784.      #error Won't work on Vaxen.  See comments at get_last_object.
  785.      #endif
  786.  
  787. *Note Nonstandard Predefined::, for why this works.
  788.  
  789.    If you have several configuration parameters that must be set up by
  790. the installation in a consistent way, you can use conditionals to detect
  791. an inconsistency and report it with `#error'.  For example,
  792.  
  793.      #if HASH_TABLE_SIZE % 2 == 0 || HASH_TABLE_SIZE % 3 == 0 \
  794.          || HASH_TABLE_SIZE % 5 == 0
  795.      #error HASH_TABLE_SIZE should not be divisible by a small prime
  796.      #endif
  797.  
  798.    The command `#warning' is like the command `#error', but causes the
  799. preprocessor to issue a warning and continue preprocessing.  The rest of
  800. the line that follows `#warning' is used as the warning message.
  801.  
  802.    You might use `#warning' in obsolete header files, with a message
  803. directing the user to the header file which should be used instead.
  804.  
  806. File: cpp.info,  Node: Combining Sources,  Next: Other Commands,  Prev: Conditionals,  Up: Top
  807.  
  808. Combining Source Files
  809. ======================
  810.  
  811.    One of the jobs of the C preprocessor is to inform the C compiler of
  812. where each line of C code came from: which source file and which line
  813. number.
  814.  
  815.    C code can come from multiple source files if you use `#include';
  816. both `#include' and the use of conditionals and macros can cause the
  817. line number of a line in the preprocessor output to be different from
  818. the line's number in the original source file.  You will appreciate the
  819. value of making both the C compiler (in error messages) and symbolic
  820. debuggers such as GDB use the line numbers in your source file.
  821.  
  822.    The C preprocessor builds on this feature by offering a command by
  823. which you can control the feature explicitly.  This is useful when a
  824. file for input to the C preprocessor is the output from another program
  825. such as the `bison' parser generator, which operates on another file
  826. that is the true source file.  Parts of the output from `bison' are
  827. generated from scratch, other parts come from a standard parser file.
  828. The rest are copied nearly verbatim from the source file, but their
  829. line numbers in the `bison' output are not the same as their original
  830. line numbers.  Naturally you would like compiler error messages and
  831. symbolic debuggers to know the original source file and line number of
  832. each line in the `bison' input.
  833.  
  834.    `bison' arranges this by writing `#line' commands into the output
  835. file.  `#line' is a command that specifies the original line number and
  836. source file name for subsequent input in the current preprocessor input
  837. file.  `#line' has three variants:
  838.  
  839. `#line LINENUM'
  840.      Here LINENUM is a decimal integer constant.  This specifies that
  841.      the line number of the following line of input, in its original
  842.      source file, was LINENUM.
  843.  
  844. `#line LINENUM FILENAME'
  845.      Here LINENUM is a decimal integer constant and FILENAME is a
  846.      string constant.  This specifies that the following line of input
  847.      came originally from source file FILENAME and its line number there
  848.      was LINENUM.  Keep in mind that FILENAME is not just a file name;
  849.      it is surrounded by doublequote characters so that it looks like a
  850.      string constant.
  851.  
  852. `#line ANYTHING ELSE'
  853.      ANYTHING ELSE is checked for macro calls, which are expanded.  The
  854.      result should be a decimal integer constant followed optionally by
  855.      a string constant, as described above.
  856.  
  857.    `#line' commands alter the results of the `__FILE__' and `__LINE__'
  858. predefined macros from that point on.  *Note Standard Predefined::.
  859.  
  860.    The output of the preprocessor (which is the input for the rest of
  861. the compiler) contains commands that look much like `#line' commands.
  862. They start with just `#' instead of `#line', but this is followed by a
  863. line number and file name as in `#line'.  *Note Output::.
  864.  
  866. File: cpp.info,  Node: Other Commands,  Next: Output,  Prev: Combining Sources,  Up: Top
  867.  
  868. Miscellaneous Preprocessor Commands
  869. ===================================
  870.  
  871.    This section describes three additional preprocessor commands.  They
  872. are not very useful, but are mentioned for completeness.
  873.  
  874.    The "null command" consists of a `#' followed by a Newline, with
  875. only whitespace (including comments) in between.  A null command is
  876. understood as a preprocessor command but has no effect on the
  877. preprocessor output.  The primary significance of the existence of the
  878. null command is that an input line consisting of just a `#' will
  879. produce no output, rather than a line of output containing just a `#'.
  880. Supposedly some old C programs contain such lines.
  881.  
  882.    The ANSI standard specifies that the `#pragma' command has an
  883. arbitrary, implementation-defined effect.  In the GNU C preprocessor,
  884. `#pragma' commands are not used, except for `#pragma once' (*note
  885. Once-Only::.).  However, they are left in the preprocessor output, so
  886. they are available to the compilation pass.
  887.  
  888.    The `#ident' command is supported for compatibility with certain
  889. other systems.  It is followed by a line of text.  On some systems, the
  890. text is copied into a special place in the object file; on most systems,
  891. the text is ignored and this command has no effect.  Typically `#ident'
  892. is only used in header files supplied with those systems where it is
  893. meaningful.
  894.  
  896. File: cpp.info,  Node: Output,  Next: Invocation,  Prev: Other Commands,  Up: Top
  897.  
  898. C Preprocessor Output
  899. =====================
  900.  
  901.    The output from the C preprocessor looks much like the input, except
  902. that all preprocessor command lines have been replaced with blank lines
  903. and all comments with spaces.  Whitespace within a line is not altered;
  904. however, a space is inserted after the expansions of most macro calls.
  905.  
  906.    Source file name and line number information is conveyed by lines of
  907. the form
  908.  
  909.      # LINENUM FILENAME FLAGS
  910.  
  911. which are inserted as needed into the middle of the input (but never
  912. within a string or character constant).  Such a line means that the
  913. following line originated in file FILENAME at line LINENUM.
  914.  
  915.    After the file name comes zero or more flags, which are `1', `2' or
  916. `3'.  If there are multiple flags, spaces separate them.  Here is what
  917. the flags mean:
  918.  
  919. `1'
  920.      This indicates the start of a new file.
  921.  
  922. `2'
  923.      This indicates returning to a file (after having included another
  924.      file).
  925.  
  926. `3'
  927.      This indicates that the following text comes from a system header
  928.      file, so certain warnings should be suppressed.
  929.  
  931. File: cpp.info,  Node: Invocation,  Next: Concept Index,  Prev: Output,  Up: Top
  932.  
  933. Invoking the C Preprocessor
  934. ===========================
  935.  
  936.    Most often when you use the C preprocessor you will not have to
  937. invoke it explicitly: the C compiler will do so automatically.
  938. However, the preprocessor is sometimes useful individually.
  939.  
  940.    The C preprocessor expects two file names as arguments, INFILE and
  941. OUTFILE.  The preprocessor reads INFILE together with any other files
  942. it specifies with `#include'.  All the output generated by the combined
  943. input files is written in OUTFILE.
  944.  
  945.    Either INFILE or OUTFILE may be `-', which as INFILE means to read
  946. from standard input and as OUTFILE means to write to standard output.
  947. Also, if OUTFILE or both file names are omitted, the standard output
  948. and standard input are used for the omitted file names.
  949.  
  950.    Here is a table of command options accepted by the C preprocessor.
  951. These options can also be given when compiling a C program; they are
  952. passed along automatically to the preprocessor when it is invoked by the
  953. compiler.
  954.  
  955. `-P'
  956.      Inhibit generation of `#'-lines with line-number information in
  957.      the output from the preprocessor (*note Output::.).  This might be
  958.      useful when running the preprocessor on something that is not C
  959.      code and will be sent to a program which might be confused by the
  960.      `#'-lines.
  961.  
  962. `-C'
  963.      Do not discard comments: pass them through to the output file.
  964.      Comments appearing in arguments of a macro call will be copied to
  965.      the output before the expansion of the macro call.
  966.  
  967. `-traditional'
  968.      Try to imitate the behavior of old-fashioned C, as opposed to ANSI
  969.      C.
  970.  
  971.         * Traditional macro expansion pays no attention to singlequote
  972.           or doublequote characters; macro argument symbols are
  973.           replaced by the argument values even when they appear within
  974.           apparent string or character constants.
  975.  
  976.         * Traditionally, it is permissible for a macro expansion to end
  977.           in the middle of a string or character constant.  The
  978.           constant continues into the text surrounding the macro call.
  979.  
  980.         * However, traditionally the end of the line terminates a
  981.           string or character constant, with no error.
  982.  
  983.         * In traditional C, a comment is equivalent to no text at all.
  984.           (In ANSI C, a comment counts as whitespace.)
  985.  
  986.         * Traditional C does not have the concept of a "preprocessing
  987.           number".  It considers `1.0e+4' to be three tokens: `1.0e',
  988.           `+', and `4'.
  989.  
  990.         * A macro is not suppressed within its own definition, in
  991.           traditional C.  Thus, any macro that is used recursively
  992.           inevitably causes an error.
  993.  
  994.         * The character `#' has no special meaning within a macro
  995.           definition in traditional C.
  996.  
  997.         * In traditional C, the text at the end of a macro expansion
  998.           can run together with the text after the macro call, to
  999.           produce a single token.  (This is impossible in ANSI C.)
  1000.  
  1001.         * Traditionally, `\' inside a macro argument suppresses the
  1002.           syntactic significance of the following character.
  1003.  
  1004. `-trigraphs'
  1005.      Process ANSI standard trigraph sequences.  These are
  1006.      three-character sequences, all starting with `??', that are
  1007.      defined by ANSI C to stand for single characters.  For example,
  1008.      `??/' stands for `\', so `'??/n'' is a character constant for a
  1009.      newline.  Strictly speaking, the GNU C preprocessor does not
  1010.      support all programs in ANSI Standard C unless `-trigraphs' is
  1011.      used, but if you ever notice the difference it will be with relief.
  1012.  
  1013.      You don't want to know any more about trigraphs.
  1014.  
  1015. `-pedantic'
  1016.      Issue warnings required by the ANSI C standard in certain cases
  1017.      such as when text other than a comment follows `#else' or `#endif'.
  1018.  
  1019. `-pedantic-errors'
  1020.      Like `-pedantic', except that errors are produced rather than
  1021.      warnings.
  1022.  
  1023. `-Wtrigraphs'
  1024.      Warn if any trigraphs are encountered (assuming they are enabled).
  1025.  
  1026. `-Wcomment'
  1027.      Warn whenever a comment-start sequence `/*' appears in a comment.
  1028.  
  1029. `-Wall'
  1030.      Requests both `-Wtrigraphs' and `-Wcomment' (but not
  1031.      `-Wtraditional').
  1032.  
  1033. `-Wtraditional'
  1034.      Warn about certain constructs that behave differently in
  1035.      traditional and ANSI C.
  1036.  
  1037. `-I DIRECTORY'
  1038.      Add the directory DIRECTORY to the end of the list of directories
  1039.      to be searched for header files (*note Include Syntax::.).  This
  1040.      can be used to override a system header file, substituting your
  1041.      own version, since these directories are searched before the system
  1042.      header file directories.  If you use more than one `-I' option,
  1043.      the directories are scanned in left-to-right order; the standard
  1044.      system directories come after.
  1045.  
  1046. `-I-'
  1047.      Any directories specified with `-I' options before the `-I-'
  1048.      option are searched only for the case of `#include "FILE"'; they
  1049.      are not searched for `#include <FILE>'.
  1050.  
  1051.      If additional directories are specified with `-I' options after
  1052.      the `-I-', these directories are searched for all `#include'
  1053.      commands.
  1054.  
  1055.      In addition, the `-I-' option inhibits the use of the current
  1056.      directory as the first search directory for `#include "FILE"'.
  1057.      Therefore, the current directory is searched only if it is
  1058.      requested explicitly with `-I.'.  Specifying both `-I-' and `-I.'
  1059.      allows you to control precisely which directories are searched
  1060.      before the current one and which are searched after.
  1061.  
  1062. `-nostdinc'
  1063.      Do not search the standard system directories for header files.
  1064.      Only the directories you have specified with `-I' options (and the
  1065.      current directory, if appropriate) are searched.
  1066.  
  1067. `-nostdinc++'
  1068.      Do not search for header files in the C++-specific standard
  1069.      directories, but do still search the other standard directories.
  1070.      (This option is used when building libg++.)
  1071.  
  1072. `-D NAME'
  1073.      Predefine NAME as a macro, with definition `1'.
  1074.  
  1075. `-D NAME=DEFINITION'
  1076.      Predefine NAME as a macro, with definition DEFINITION.  There are
  1077.      no restrictions on the contents of DEFINITION, but if you are
  1078.      invoking the preprocessor from a shell or shell-like program you
  1079.      may need to use the shell's quoting syntax to protect characters
  1080.      such as spaces that have a meaning in the shell syntax.  If you
  1081.      use more than one `-D' for the same NAME, the rightmost definition
  1082.      takes effect.
  1083.  
  1084. `-U NAME'
  1085.      Do not predefine NAME.  If both `-U' and `-D' are specified for
  1086.      one name, the `-U' beats the `-D' and the name is not predefined.
  1087.  
  1088. `-undef'
  1089.      Do not predefine any nonstandard macros.
  1090.  
  1091. `-A PREDICATE(ANSWER)'
  1092.      Make an assertion with the predicate PREDICATE and answer ANSWER.
  1093.      *Note Assertions::.
  1094.  
  1095.      You can use `-A-' to disable all predefined assertions; it also
  1096.      undefines all predefined macros that identify the type of target
  1097.      system.
  1098.  
  1099. `-dM'
  1100.      Instead of outputting the result of preprocessing, output a list of
  1101.      `#define' commands for all the macros defined during the execution
  1102.      of the preprocessor, including predefined macros.  This gives you
  1103.      a way of finding out what is predefined in your version of the
  1104.      preprocessor; assuming you have no file `foo.h', the command
  1105.  
  1106.           touch foo.h; cpp -dM foo.h
  1107.  
  1108.      will show the values of any predefined macros.
  1109.  
  1110. `-dD'
  1111.      Like `-dM' except in two respects: it does *not* include the
  1112.      predefined macros, and it outputs *both* the `#define' commands
  1113.      and the result of preprocessing.  Both kinds of output go to the
  1114.      standard output file.
  1115.  
  1116. `-M'
  1117.      Instead of outputting the result of preprocessing, output a rule
  1118.      suitable for `make' describing the dependencies of the main source
  1119.      file.  The preprocessor outputs one `make' rule containing the
  1120.      object file name for that source file, a colon, and the names of
  1121.      all the included files.  If there are many included files then the
  1122.      rule is split into several lines using `\'-newline.
  1123.  
  1124.      This feature is used in automatic updating of makefiles.
  1125.  
  1126. `-MM'
  1127.      Like `-M' but mention only the files included with `#include
  1128.      "FILE"'.  System header files included with `#include <FILE>' are
  1129.      omitted.
  1130.  
  1131. `-MD'
  1132.      Like `-M' but the dependency information is written to files with
  1133.      names made by replacing `.c' with `.d' at the end of the input
  1134.      file names.  This is in addition to compiling the file as
  1135.      specified--`-MD' does not inhibit ordinary compilation the way
  1136.      `-M' does.
  1137.  
  1138.      In Mach, you can use the utility `md' to merge the `.d' files into
  1139.      a single dependency file suitable for using with the `make'
  1140.      command.
  1141.  
  1142. `-MMD'
  1143.      Like `-MD' except mention only user header files, not system
  1144.      header files.
  1145.  
  1146. `-H'
  1147.      Print the name of each header file used, in addition to other
  1148.      normal activities.
  1149.  
  1150. `-imacros FILE'
  1151.      Process FILE as input, discarding the resulting output, before
  1152.      processing the regular input file.  Because the output generated
  1153.      from FILE is discarded, the only effect of `-imacros FILE' is to
  1154.      make the macros defined in FILE available for use in the main
  1155.      input.
  1156.  
  1157. `-include FILE'
  1158.      Process FILE as input, and include all the resulting output,
  1159.      before processing the regular input file.
  1160.  
  1161. `-idirafter DIR'
  1162.      Add the directory DIR to the second include path.  The directories
  1163.      on the second include path are searched when a header file is not
  1164.      found in any of the directories in the main include path (the one
  1165.      that `-I' adds to).
  1166.  
  1167. `-iprefix PREFIX'
  1168.      Specify PREFIX as the prefix for subsequent `-iwithprefix' options.
  1169.  
  1170. `-iwithprefix DIR'
  1171.      Add a directory to the second include path.  The directory's name
  1172.      is made by concatenating PREFIX and DIR, where PREFIX was
  1173.      specified previously with `-iprefix'.
  1174.  
  1175. `-lang-c'
  1176. `-lang-c++'
  1177. `-lang-objc'
  1178. `-lang-objc++'
  1179.      Specify the source language.  `-lang-c++' makes the preprocessor
  1180.      handle C++ comment syntax (comments may begin with `//', in which
  1181.      case they end at end of line), and includes extra default include
  1182.      directories for C++; and `-lang-objc' enables the Objective C
  1183.      `#import' command.  `-lang-c' explicitly turns off both of these
  1184.      extensions, and `-lang-objc++' enables both.
  1185.  
  1186.      These options are generated by the compiler driver `gcc', but not
  1187.      passed from the `gcc' command line.
  1188.  
  1189. `-lint'
  1190.      Look for commands to the program checker `lint' embedded in
  1191.      comments, and emit them preceded by `#pragma lint'.  For example,
  1192.      the comment `/* NOTREACHED */' becomes `#pragma lint NOTREACHED'.
  1193.  
  1194.      This option is available only when you call `cpp' directly; `gcc'
  1195.      will not pass it from its command line.
  1196.  
  1197. `-$'
  1198.      Forbid the use of `$' in identifiers.  This is required for ANSI
  1199.      conformance.  `gcc' automatically supplies this option to the
  1200.      preprocessor if you specify `-ansi', but `gcc' doesn't recognize
  1201.      the `-$' option itself--to use it without the other effects of
  1202.      `-ansi', you must call the preprocessor directly.
  1203.  
  1205. File: cpp.info,  Node: Concept Index,  Next: Index,  Prev: Invocation,  Up: Top
  1206.  
  1207. Concept Index
  1208. *************
  1209.  
  1210. * Menu:
  1211.  
  1212. * assertions:                           Assertions.
  1213. * assertions, undoing:                  Assertions.
  1214. * cascaded macros:                      Cascaded Macros.
  1215. * commands:                             Commands.
  1216. * concatenation:                        Concatenation.
  1217. * conditionals:                         Conditionals.
  1218. * header file:                          Header Files.
  1219. * inheritance:                          Inheritance.
  1220. * line control:                         Combining Sources.
  1221. * macro body uses macro:                Cascaded Macros.
  1222. * null command:                         Other Commands.
  1223. * options:                              Invocation.
  1224. * output format:                        Output.
  1225. * overriding a header file:             Inheritance.
  1226. * predefined macros:                    Predefined.
  1227. * predicates:                           Assertions.
  1228. * preprocessor commands:                Commands.
  1229. * redefining macros:                    Redefining.
  1230. * repeated inclusion:                   Once-Only.
  1231. * retracting assertions:                Assertions.
  1232. * second include path:                  Invocation.
  1233. * self-reference:                       Self-Reference.
  1234. * semicolons (after macro calls):       Swallow Semicolon.
  1235. * side effects (in macro arguments):    Side Effects.
  1236. * stringification:                      Stringification.
  1237. * testing predicates:                   Assertions.
  1238. * unassert:                             Assertions.
  1239. * undefining macros:                    Undefining.
  1240. * unsafe macros:                        Side Effects.
  1241.  
  1242.