![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to cpp.info-2 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to cpp.info-2 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.2 ! root 1: This is Info file cpp.info, produced by Makeinfo-1.49 from the input ! 2: file cpp.texi. 1.1 root 3: 4: This file documents the GNU C Preprocessor. 5: 1.1.1.2 ! root 6: Copyright (C) 1987, 1989, 1991, 1992 Free Software Foundation, Inc. 1.1 root 7: 1.1.1.2 ! root 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. 1.1 root 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: 21: 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: 1.1.1.2 ! root 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. 1.1 root 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 1.1.1.2 ! root 57: statement--in between the `if' condition and the `else' makes invalid C ! 58: code. 1.1 root 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: 76: 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 1.1.1.2 ! root 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. 1.1 root 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: 127: 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 1.1.1.2 ! root 134: definition. A special feature of ANSI Standard C is that the 1.1 root 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 1.1.1.2 ! root 146: + (4 + foo))'; and so on until it causes a fatal error (memory full) in ! 147: the preprocessor. 1.1 root 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: 1.1.1.2 ! root 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 1.1 root 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 1.1.1.2 ! root 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 1.1 root 165: 166: #define x (4 + y) 167: #define y (2 * x) 168: 169: `x' would expand into `(4 + (2 * x))'. Clear? 170: 1.1.1.2 ! root 171: But suppose `y' is used elsewhere, not from the definition of `x'. 1.1 root 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 1.1.1.2 ! root 175: self-reference now because `y' is "in progress". The result is that `y' ! 176: expands to `(2 * (4 + y))'. 1.1 root 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: 181: 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 1.1.1.2 ! root 193: substituted into the macro body to produce the macro expansion, and the ! 194: macro expansion is scanned again for macros to expand. 1.1 root 195: 1.1.1.2 ! root 196: The result is that the actual arguments are scanned *twice* to expand ! 197: macro calls in them. 1.1 root 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 1.1.1.2 ! root 202: not change it. If the actual argument were substituted as given, with 1.1 root 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 1.1.1.2 ! root 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. 1.1 root 213: 214: The prescan is not done when an argument is stringified or 1.1.1.2 ! root 215: concatenated. Thus, 1.1 root 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: 1.1.1.2 ! root 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 1.1 root 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 1.1.1.2 ! root 236: difference? And why not skip it and make the preprocessor faster?" The ! 237: answer is that the prescan does make a difference in three special 1.1 root 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 1.1.1.2 ! root 251: expected result to happen. Without the prescan, `f (1)' itself would be ! 252: substituted as an actual argument, and the inner use of `f' would appear ! 253: during the main scan as an indirect self-reference and would not be ! 254: expanded. Here, the prescan cancels an undesirable side effect (in the ! 255: medical, not computational, sense of the term) of the special rule for ! 256: self-referential macros. 1.1 root 257: 258: But prescan causes trouble in certain other cases of nested macro 1.1.1.2 ! root 259: calls. Here is an example: 1.1 root 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 1.1.1.2 ! root 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: 1.1 root 296: 297: #define xstr(s) str(s) 298: #define str(s) #s 299: #define foo 4 300: xstr (foo) 301: 1.1.1.2 ! root 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'. 1.1 root 308: 309: 1.1.1.2 ! root 310: File: cpp.info, Node: Cascaded Macros, Next: Newlines in Args, Prev: Argument Prescan, Up: Macro Pitfalls 1.1 root 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: 1.1.1.2 ! root 321: This is not at all the same as defining `TABLESIZE' to be `1020'. 1.1 root 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: 1.1.1.2 ! root 326: It's only when you *use* `TABLESIZE' that the result of its expansion ! 327: is checked for more macro names. 1.1 root 328: 1.1.1.2 ! root 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 1.1 root 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: 341: 1.1.1.2 ! root 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: ! 374: 1.1 root 375: File: cpp.info, Node: Conditionals, Next: Combining Sources, Prev: Macros, Up: Top 376: 377: Conditionals 378: ============ 379: 1.1.1.2 ! root 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. In ! 382: the C preprocessor, a conditional can test either an arithmetic ! 383: expression or whether a name is defined as a macro. 1.1 root 384: 385: A conditional in the C preprocessor resembles in some ways an `if' 1.1.1.2 ! root 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. 1.1 root 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. 1.1.1.2 ! root 401: * Assertions:: How and why to use assertions. 1.1 root 402: * Errors: #error Command. Detecting inconsistent compilation parameters. 403: 404: 1.1.1.2 ! root 405: File: cpp.info, Node: Conditional Uses, Next: Conditional Syntax, Up: Conditionals 1.1 root 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 1.1.1.2 ! root 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. 1.1 root 421: 422: * You may want to be able to compile the same source file into two 1.1.1.2 ! root 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. 1.1 root 426: 427: * A conditional whose condition is always false is a good way to 1.1.1.2 ! root 428: exclude code from the program but keep it as a sort of comment for ! 429: future reference. 1.1 root 430: 431: Most simple programs that are intended to run on only one machine 432: will not need to use preprocessor conditionals. 433: 434: 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 1.1.1.2 ! root 441: command": `#if', `#ifdef' or `#ifndef'. *Note Conditionals-Macros::, ! 442: for information on `#ifdef' and `#ifndef'; only `#if' is explained here. 1.1 root 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: 450: 1.1.1.2 ! root 451: File: cpp.info, Node: #if Command, Next: #else Command, Up: Conditional Syntax 1.1 root 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 1.1.1.2 ! root 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. 1.1 root 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: 1.1.1.2 ! root 491: * Macro calls. All macro calls in the expression are expanded before ! 492: actual computation of the expression's value begins. 1.1 root 493: 1.1.1.2 ! root 494: Note that `sizeof' operators and `enum'-type values are not allowed. 1.1 root 495: `enum'-type values, like all other identifiers that are not taken as 496: macro calls and expanded, are treated as zero. 497: 1.1.1.2 ! root 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. 1.1 root 503: 504: 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 1.1.1.2 ! root 511: alternative text to be used if the condition is false. This is what it ! 512: looks like: 1.1 root 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: 525: 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 1.1.1.2 ! root 557: matching `#endif' of its own. Like `#if', the `#elif' command includes ! 558: an expression to be tested. 1.1 root 559: 560: The text following the `#elif' is processed only if the original 1.1.1.2 ! root 561: `#if'-condition failed and the `#elif' condition succeeds. More than 1.1 root 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 1.1.1.2 ! root 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'. 1.1 root 568: 569: 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: 582: 1.1.1.2 ! root 583: File: cpp.info, Node: Conditionals-Macros, Next: Assertions, Prev: Deleted Code, Up: Conditionals 1.1 root 584: 585: Conditionals and Macros 586: ----------------------- 587: 1.1.1.2 ! root 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 compilaton 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. 1.1 root 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: 1.1.1.2 ! root 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, 1.1 root 614: 615: #if defined (vax) || defined (ns16000) 616: 617: would include the following code if either of the names `vax' and 1.1.1.2 ! root 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) 1.1 root 622: 623: If a macro is defined and later undefined with `#undef', subsequent 1.1.1.2 ! root 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', 1.1 root 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 1.1.1.2 ! root 630: case. 1.1 root 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 1.1.1.2 ! root 647: conditionals to avoid using a system feature on a machine where it ! 648: is not implemented. 1.1 root 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 1.1.1.2 ! root 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 1.1 root 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 1.1.1.2 ! root 662: the state of the macro with compiler command options. *Note 1.1 root 663: Invocation::. 664: 1.1.1.2 ! root 665: Assertions are usually predefined, but can be defined with ! 666: preprocessor commands or command-line options. ! 667: 1.1 root 668: 1.1.1.2 ! root 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', `cpu', ! 709: and `machine'. `system' is for assertions about the type of software, ! 710: `cpu' describes the type of computer architecture, and `machine' gives ! 711: more information about the computer. For example, on a GNU system, the ! 712: 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. On a Unix system, you would find `#system (unix)' ! 722: and either `#system (unix bsd)' or `#system (unix sysv)', with possible ! 723: version numbers following. The alternatives with more or less version ! 724: information let you ask more or less detailed questions about the type ! 725: of system software. ! 726: ! 727: *Portability note:* Many Unix C compilers provide only one answer ! 728: for the `system' assertion: `#system (unix)', if they support ! 729: assertions at all. This is less than useful. ! 730: ! 731: An assertion with a multi-word answer is completely different from ! 732: several assertions with individual single-word answers. For example, ! 733: the presence of `system (mach 3.0)' does not mean that `system (3.0)' ! 734: is true. It also does not directly imply `system (mach)', but in GNU C, ! 735: that last will normally be asserted as well. ! 736: ! 737: You can create assertions within a C program using `#assert', like ! 738: this: ! 739: ! 740: #assert PREDICATE (ANSWER) ! 741: ! 742: (Note the absence of a `#' before PREDICATE.) ! 743: ! 744: Each time you do this, you assert a new true answer for PREDICATE. ! 745: Asserting one answer does not invalidate previously asserted answers; ! 746: they all remain true. The only way to remove an assertion is with ! 747: `#unassert'. `#unassert' has the same syntax as `#assert'. You can ! 748: also remove all assertions about PREDICATE like this: ! 749: ! 750: #unassert PREDICATE ! 751: ! 752: You can also add or cancel assertions using command options when you ! 753: run `gcc' or `cpp'. *Note Invocation::. ! 754: ! 755: ! 756: File: cpp.info, Node: #error Command, Prev: Assertions, Up: Conditionals 1.1 root 757: 758: The `#error' and `#warning' Commands 759: ------------------------------------ 760: 761: The command `#error' causes the preprocessor to report a fatal 1.1.1.2 ! root 762: error. The rest of the line that follows `#error' is used as the error ! 763: message. 1.1 root 764: 765: You would use `#error' inside of a conditional that detects a 766: combination of parameters which you know the program does not properly 767: support. For example, if you know that the program will not run 768: properly on a Vax, you might write 769: 770: #ifdef vax 771: #error Won't work on Vaxen. See comments at get_last_object. 772: #endif 773: 774: *Note Nonstandard Predefined::, for why this works. 775: 776: If you have several configuration parameters that must be set up by 1.1.1.2 ! root 777: the installation in a consistent way, you can use conditionals to detect ! 778: an inconsistency and report it with `#error'. For example, 1.1 root 779: 780: #if HASH_TABLE_SIZE % 2 == 0 || HASH_TABLE_SIZE % 3 == 0 \ 781: || HASH_TABLE_SIZE % 5 == 0 782: #error HASH_TABLE_SIZE should not be divisible by a small prime 783: #endif 784: 785: The command `#warning' is like the command `#error', but causes the 1.1.1.2 ! root 786: preprocessor to issue a warning and continue preprocessing. The rest of ! 787: the line that follows `#warning' is used as the warning message. 1.1 root 788: 789: You might use `#warning' in obsolete header files, with a message 790: directing the user to the header file which should be used instead. 791: 792: 793: File: cpp.info, Node: Combining Sources, Next: Other Commands, Prev: Conditionals, Up: Top 794: 795: Combining Source Files 796: ====================== 797: 1.1.1.2 ! root 798: One of the jobs of the C preprocessor is to inform the C compiler of ! 799: where each line of C code came from: which source file and which line ! 800: number. 1.1 root 801: 802: C code can come from multiple source files if you use `#include'; 803: both `#include' and the use of conditionals and macros can cause the 804: line number of a line in the preprocessor output to be different from 1.1.1.2 ! root 805: the line's number in the original source file. You will appreciate the ! 806: value of making both the C compiler (in error messages) and symbolic ! 807: debuggers such as GDB use the line numbers in your source file. 1.1 root 808: 809: The C preprocessor builds on this feature by offering a command by 810: which you can control the feature explicitly. This is useful when a 1.1.1.2 ! root 811: file for input to the C preprocessor is the output from another program ! 812: such as the `bison' parser generator, which operates on another file ! 813: that is the true source file. Parts of the output from `bison' are ! 814: generated from scratch, other parts come from a standard parser file. ! 815: The rest are copied nearly verbatim from the source file, but their ! 816: line numbers in the `bison' output are not the same as their original ! 817: line numbers. Naturally you would like compiler error messages and ! 818: symbolic debuggers to know the original source file and line number of ! 819: each line in the `bison' input. 1.1 root 820: 821: `bison' arranges this by writing `#line' commands into the output 1.1.1.2 ! root 822: file. `#line' is a command that specifies the original line number and ! 823: source file name for subsequent input in the current preprocessor input ! 824: file. `#line' has three variants: 1.1 root 825: 826: `#line LINENUM' 827: Here LINENUM is a decimal integer constant. This specifies that 828: the line number of the following line of input, in its original 829: source file, was LINENUM. 830: 831: `#line LINENUM FILENAME' 832: Here LINENUM is a decimal integer constant and FILENAME is a 833: string constant. This specifies that the following line of input 1.1.1.2 ! root 834: came originally from source file FILENAME and its line number there ! 835: was LINENUM. Keep in mind that FILENAME is not just a file name; ! 836: it is surrounded by doublequote characters so that it looks like a ! 837: string constant. 1.1 root 838: 839: `#line ANYTHING ELSE' 1.1.1.2 ! root 840: ANYTHING ELSE is checked for macro calls, which are expanded. The ! 841: result should be a decimal integer constant followed optionally by ! 842: a string constant, as described above. 1.1 root 843: 844: `#line' commands alter the results of the `__FILE__' and `__LINE__' 845: predefined macros from that point on. *Note Standard Predefined::. 846: 1.1.1.2 ! root 847: The output of the preprocessor (which is the input for the rest of ! 848: the compiler) contains commands that look much like `#line' commands. ! 849: They start with just `#' instead of `#line', but this is followed by a ! 850: line number and file name as in `#line'. *Note Output::. ! 851: 1.1 root 852: 853: File: cpp.info, Node: Other Commands, Next: Output, Prev: Combining Sources, Up: Top 854: 855: Miscellaneous Preprocessor Commands 856: =================================== 857: 1.1.1.2 ! root 858: This section describes three additional preprocessor commands. They ! 859: are not very useful, but are mentioned for completeness. 1.1 root 860: 861: The "null command" consists of a `#' followed by a Newline, with 862: only whitespace (including comments) in between. A null command is 863: understood as a preprocessor command but has no effect on the 864: preprocessor output. The primary significance of the existence of the 865: null command is that an input line consisting of just a `#' will 1.1.1.2 ! root 866: produce no output, rather than a line of output containing just a `#'. ! 867: Supposedly some old C programs contain such lines. 1.1 root 868: 869: The ANSI standard specifies that the `#pragma' command has an 870: arbitrary, implementation-defined effect. In the GNU C preprocessor, 871: `#pragma' commands are ignored, except for `#pragma once' (*note 872: Once-Only::.). 873: 874: The `#ident' command is supported for compatibility with certain 875: other systems. It is followed by a line of text. On some systems, the 1.1.1.2 ! root 876: text is copied into a special place in the object file; on most systems, ! 877: the text is ignored and this command has no effect. Typically `#ident' ! 878: is only used in header files supplied with those systems where it is ! 879: meaningful. 1.1 root 880: 881: 882: File: cpp.info, Node: Output, Next: Invocation, Prev: Other Commands, Up: Top 883: 884: C Preprocessor Output 885: ===================== 886: 887: The output from the C preprocessor looks much like the input, except 888: that all preprocessor command lines have been replaced with blank lines 889: and all comments with spaces. Whitespace within a line is not altered; 890: however, a space is inserted after the expansions of most macro calls. 891: 892: Source file name and line number information is conveyed by lines of 893: the form 894: 1.1.1.2 ! root 895: # LINENUM FILENAME FLAGS 1.1 root 896: 897: which are inserted as needed into the middle of the input (but never 898: within a string or character constant). Such a line means that the 899: following line originated in file FILENAME at line LINENUM. 900: 1.1.1.2 ! root 901: After the file name comes zero or more flags, which are `1', `2' or ! 902: `3'. If there are multiple flags, spaces separate them. Here is what ! 903: the flags mean: ! 904: ! 905: `1' ! 906: This indicates the start of a new file. ! 907: ! 908: `2' ! 909: This indicates returning to a file (after having included another ! 910: file). ! 911: ! 912: `3' ! 913: This indicates that the following text comes from a system header ! 914: file, so certain warnings should be suppressed. 1.1 root 915: 916: 917: File: cpp.info, Node: Invocation, Next: Concept Index, Prev: Output, Up: Top 918: 919: Invoking the C Preprocessor 920: =========================== 921: 922: Most often when you use the C preprocessor you will not have to 923: invoke it explicitly: the C compiler will do so automatically. 924: However, the preprocessor is sometimes useful individually. 925: 926: The C preprocessor expects two file names as arguments, INFILE and 927: OUTFILE. The preprocessor reads INFILE together with any other files 1.1.1.2 ! root 928: it specifies with `#include'. All the output generated by the combined ! 929: input files is written in OUTFILE. 1.1 root 930: 931: Either INFILE or OUTFILE may be `-', which as INFILE means to read 932: from standard input and as OUTFILE means to write to standard output. 933: Also, if OUTFILE or both file names are omitted, the standard output 934: and standard input are used for the omitted file names. 935: 1.1.1.2 ! root 936: Here is a table of command options accepted by the C preprocessor. 1.1 root 937: These options can also be given when compiling a C program; they are 1.1.1.2 ! root 938: passed along automatically to the preprocessor when it is invoked by the ! 939: compiler. 1.1 root 940: 941: `-P' 942: Inhibit generation of `#'-lines with line-number information in 943: the output from the preprocessor (*note Output::.). This might be 944: useful when running the preprocessor on something that is not C 945: code and will be sent to a program which might be confused by the 946: `#'-lines. 947: 948: `-C' 1.1.1.2 ! root 949: Do not discard comments: pass them through to the output file. 1.1 root 950: Comments appearing in arguments of a macro call will be copied to 951: the output before the expansion of the macro call. 952: 1.1.1.2 ! root 953: `-traditional' ! 954: Try to imitate the behavior of old-fashioned C, as opposed to ANSI ! 955: C. ! 956: ! 957: * Traditional macro expansion pays no attention to singlequote ! 958: or doublequote characters; macro argument symbols are ! 959: replaced by the argument values even when they appear within ! 960: apparent string or character constants. ! 961: ! 962: * Traditionally, it is permissable for a macro expansion to end ! 963: in the middle of a string or character constant. The ! 964: constant continues into the text surrounding the macro call. ! 965: ! 966: * However, traditionally the end of the line terminates a ! 967: string or character constant, with no error. ! 968: ! 969: * In traditional C, a comment is equivalent to no text at all. ! 970: (In ANSI C, a comment counts as whitespace.) ! 971: ! 972: * Traditional C does not have the concept of a "preprocessing ! 973: number". It considers `1.0e+4' to be three tokens: `1.0e', ! 974: `+', and `4'. ! 975: ! 976: * A macro is not suppressed within its own definition, in ! 977: traditional C. Thus, any macro that is used recursively ! 978: inevitably causes an error. ! 979: ! 980: * The character `#' has no special meaning within a macro ! 981: definition in traditional C. ! 982: ! 983: * In traditional C, the text at the end of a macro expansion ! 984: can run together with the text after the macro call, to ! 985: produce a single token. (This is impossible in ANSI C.) ! 986: ! 987: * Traditionally, `\' inside a macro argument suppresses the ! 988: syntactic significance of the following character. ! 989: 1.1 root 990: `-trigraphs' 991: Process ANSI standard trigraph sequences. These are 992: three-character sequences, all starting with `??', that are 993: defined by ANSI C to stand for single characters. For example, 994: `??/' stands for `\', so `'??/n'' is a character constant for a 1.1.1.2 ! root 995: newline. Strictly speaking, the GNU C preprocessor does not 1.1 root 996: support all programs in ANSI Standard C unless `-trigraphs' is 1.1.1.2 ! root 997: used, but if you ever notice the difference it will be with relief. 1.1 root 998: 999: You don't want to know any more about trigraphs. 1000: 1001: `-pedantic' 1002: Issue warnings required by the ANSI C standard in certain cases 1.1.1.2 ! root 1003: such as when text other than a comment follows `#else' or `#endif'. 1.1 root 1004: 1005: `-pedantic-errors' 1006: Like `-pedantic', except that errors are produced rather than 1007: warnings. 1008: 1009: `-Wtrigraphs' 1010: Warn if any trigraphs are encountered (assuming they are enabled). 1011: 1012: `-Wcomment' 1013: Warn whenever a comment-start sequence `/*' appears in a comment. 1014: 1015: `-Wall' 1016: Requests both `-Wtrigraphs' and `-Wcomment' (but not 1017: `-Wtraditional'). 1018: 1019: `-Wtraditional' 1020: Warn about certain constructs that behave differently in 1021: traditional and ANSI C. 1022: 1023: `-I DIRECTORY' 1024: Add the directory DIRECTORY to the end of the list of directories 1.1.1.2 ! root 1025: to be searched for header files (*note Include Syntax::.). This 1.1 root 1026: can be used to override a system header file, substituting your 1.1.1.2 ! root 1027: own version, since these directories are searched before the system ! 1028: header file directories. If you use more than one `-I' option, ! 1029: the directories are scanned in left-to-right order; the standard ! 1030: system directories come after. 1.1 root 1031: 1032: `-I-' 1033: Any directories specified with `-I' options before the `-I-' 1034: option are searched only for the case of `#include "FILE"'; they 1035: are not searched for `#include <FILE>'. 1036: 1037: If additional directories are specified with `-I' options after 1038: the `-I-', these directories are searched for all `#include' 1.1.1.2 ! root 1039: commands. 1.1 root 1040: 1041: In addition, the `-I-' option inhibits the use of the current 1.1.1.2 ! root 1042: directory as the first search directory for `#include "FILE"'. 1.1 root 1043: Therefore, the current directory is searched only if it is 1044: requested explicitly with `-I.'. Specifying both `-I-' and `-I.' 1045: allows you to control precisely which directories are searched 1046: before the current one and which are searched after. 1047: 1048: `-nostdinc' 1.1.1.2 ! root 1049: Do not search the standard system directories for header files. ! 1050: Only the directories you have specified with `-I' options (and the ! 1051: current directory, if appropriate) are searched. 1.1 root 1052: 1053: `-nostdinc++' 1054: Do not search for header files in the C++-specific standard 1.1.1.2 ! root 1055: directories, but do still search the other standard directories. 1.1 root 1056: (This option is used when building `libg++'.) 1057: 1058: `-D NAME' 1059: Predefine NAME as a macro, with definition `1'. 1060: 1061: `-D NAME=DEFINITION' 1.1.1.2 ! root 1062: Predefine NAME as a macro, with definition DEFINITION. There are 1.1 root 1063: no restrictions on the contents of DEFINITION, but if you are 1064: invoking the preprocessor from a shell or shell-like program you 1065: may need to use the shell's quoting syntax to protect characters 1066: such as spaces that have a meaning in the shell syntax. If you 1.1.1.2 ! root 1067: use more than one `-D' for the same NAME, the rightmost definition ! 1068: takes effect. 1.1 root 1069: 1070: `-U NAME' 1071: Do not predefine NAME. If both `-U' and `-D' are specified for 1072: one name, the `-U' beats the `-D' and the name is not predefined. 1073: 1.1.1.2 ! root 1074: `-A PREDICATE(ANSWER)' ! 1075: Make an assertion with the predicate PREDICATE and answer ANSWER. ! 1076: *Note Assertions::. ! 1077: ! 1078: You can use `-A-' to disable all predefined assertions; it also ! 1079: undefines all predefined macros that identify the type of target ! 1080: system. 1.1 root 1081: 1082: `-dM' 1.1.1.2 ! root 1083: Instead of outputting the result of preprocessing, output a list of ! 1084: `#define' commands for all the macros defined during the execution ! 1085: of the preprocessor, including predefined macros. This gives you ! 1086: a way of finding out what is predefined in your version of the ! 1087: preprocessor; assuming you have no file `foo.h', the command 1.1 root 1088: 1089: touch foo.h; cpp -dM foo.h 1090: 1091: will show the values of any predefined macros. 1092: 1093: `-dD' 1094: Like `-dM' except in two respects: it does *not* include the 1095: predefined macros, and it outputs *both* the `#define' commands 1096: and the result of preprocessing. Both kinds of output go to the 1097: standard output file. 1098: 1099: `-M' 1100: Instead of outputting the result of preprocessing, output a rule 1.1.1.2 ! root 1101: suitable for `make' describing the dependencies of the main source ! 1102: file. The preprocessor outputs one `make' rule containing the ! 1103: object file name for that source file, a colon, and the names of ! 1104: all the included files. If there are many included files then the ! 1105: rule is split into several lines using `\'-newline. 1.1 root 1106: 1107: This feature is used in automatic updating of makefiles. 1108: 1109: `-MM' 1110: Like `-M' but mention only the files included with `#include 1111: "FILE"'. System header files included with `#include <FILE>' are 1112: omitted. 1113: 1114: `-MD' 1115: Like `-M' but the dependency information is written to files with 1116: names made by replacing `.c' with `.d' at the end of the input 1117: file names. This is in addition to compiling the file as 1118: specified--`-MD' does not inhibit ordinary compilation the way 1119: `-M' does. 1120: 1.1.1.2 ! root 1121: In Mach, you can use the utility `md' to merge the `.d' files into ! 1122: a single dependency file suitable for using with the `make' 1.1 root 1123: command. 1124: 1125: `-MMD' 1126: Like `-MD' except mention only user header files, not system 1127: header files. 1128: 1129: `-H' 1130: Print the name of each header file used, in addition to other 1131: normal activities. 1132: 1133: `-imacros FILE' 1134: Process FILE as input, discarding the resulting output, before 1135: processing the regular input file. Because the output generated 1136: from FILE is discarded, the only effect of `-imacros FILE' is to 1137: make the macros defined in FILE available for use in the main 1138: input. 1139: 1140: `-include FILE' 1141: Process FILE as input, and include all the resulting output, 1142: before processing the regular input file. 1143: 1144: `-lang-c' 1145: `-lang-c++' 1146: `-lang-objc' 1147: `-lang-objc++' 1148: Specify the source language. `-lang-c++' makes the preprocessor 1149: handle C++ comment syntax, and includes extra default include 1150: directories for C++, and `-lang-objc' enables the Objective C 1.1.1.2 ! root 1151: `#import' command. `-lang-c' explicitly turns off both of these ! 1152: extensions, and `-lang-objc++' enables both. 1.1 root 1153: 1154: These options are generated by the compiler driver `gcc', but not 1155: passed from the `gcc' command line. 1156: 1157: `-lint' 1158: Look for commands to the program checker `lint' embedded in 1159: comments, and emit them preceded by `#pragma lint'. For example, 1160: the comment `/* NOTREACHED */' becomes `#pragma lint NOTREACHED'. 1161: 1162: This option is available only when you call `cpp' directly; `gcc' 1163: will not pass it from its command line. 1164: 1165: `-$' 1166: Forbid the use of `$' in identifiers. This is required for ANSI 1167: conformance. `gcc' automatically supplies this option to the 1168: preprocessor if you specify `-ansi', but `gcc' doesn't recognize 1169: the `-$' option itself--to use it without the other effects of 1170: `-ansi', you must call the preprocessor directly. 1171: 1172: 1173: File: cpp.info, Node: Concept Index, Next: Index, Prev: Invocation, Up: Top 1174: 1175: Concept Index 1176: ************* 1177: 1178: * Menu: 1179: 1.1.1.2 ! root 1180: * assertions: Assertions. ! 1181: * assertions, undoing: Assertions. 1.1 root 1182: * cascaded macros: Cascaded Macros. 1183: * commands: Commands. 1184: * concatenation: Concatenation. 1185: * conditionals: Conditionals. 1186: * header file: Header Files. 1187: * inheritance: Inheritance. 1188: * line control: Combining Sources. 1189: * macro body uses macro: Cascaded Macros. 1190: * null command: Other Commands. 1191: * options: Invocation. 1192: * output format: Output. 1193: * overriding a header file: Inheritance. 1194: * predefined macros: Predefined. 1.1.1.2 ! root 1195: * predicates: Assertions. 1.1 root 1196: * preprocessor commands: Commands. 1197: * redefining macros: Redefining. 1198: * repeated inclusion: Once-Only. 1.1.1.2 ! root 1199: * retracting assertions: Assertions. 1.1 root 1200: * self-reference: Self-Reference. 1201: * semicolons (after macro calls): Swallow Semicolon. 1202: * side effects (in macro arguments): Side Effects. 1203: * stringification: Stringification. 1.1.1.2 ! root 1204: * testing predicates: Assertions. ! 1205: * unassert: Assertions. 1.1 root 1206: * undefining macros: Undefining. 1207: * unsafe macros: Side Effects. 1208: 1.1.1.2 ! root 1209:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.