![[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.3 ! root 1: This is Info file cpp.info, produced by Makeinfo-1.54 from the input 1.1.1.2 root 2: file cpp.texi. 1.1 root 3: 4: This file documents the GNU C Preprocessor. 5: 1.1.1.3 ! root 6: Copyright 1987, 1989, 1991, 1992, 1993 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.3 ! 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.3 ! root 175: self-reference now because `y' is "in progress". The result is that ! 176: `y' 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 1.1.1.3 ! root 200: contained any macro calls, they are expanded during the first scan. 1.1 root 201: The result therefore contains no macro calls, so the second scan does 1.1.1.3 ! 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.3 ! 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.3 ! root 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 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.3 ! root 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. 1.1 root 257: 258: But prescan causes trouble in certain other cases of nested macro 1.1.1.3 ! 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' 1.1.1.3 ! root 304: does not specify stringification or concatenation of the argument). 1.1.1.2 root 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 1.1.1.3 ! root 381: of the program to be ignored during compilation, on some conditions. ! 382: In the C preprocessor, a conditional can test either an arithmetic 1.1.1.2 root 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 1.1.1.3 ! root 389: differently from run to run, depending on the data it is operating on. 1.1.1.2 root 390: The condition in a preprocessor conditional command is tested when your 1.1.1.3 ! root 391: program is compiled. Its purpose is to allow different code to be 1.1.1.2 root 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.3 ! root 441: command": `#if', `#ifdef' or `#ifndef'. *Note Conditionals-Macros::, 1.1.1.2 root 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.3 ! 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 1.1.1.3 ! root 590: from one compilation to another. A `#if' command whose expression uses 1.1.1.2 root 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.3 ! 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 1.1.1.3 ! root 685: an answer. The question is usually called the "predicate". An 1.1.1.2 root 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 1.1.1.3 ! root 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: 1.1.1.2 root 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)' 1.1.1.3 ! root 734: is true. It also does not directly imply `system (mach)', but in GNU ! 735: C, that last will normally be asserted as well. 1.1.1.2 root 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 1.1.1.3 ! root 814: generated from scratch, other parts come from a standard parser file. 1.1.1.2 root 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 1.1.1.3 ! root 817: line numbers. Naturally you would like compiler error messages and 1.1.1.2 root 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.3 ! root 840: ANYTHING ELSE is checked for macro calls, which are expanded. The 1.1.1.2 root 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.3 ! root 866: produce no output, rather than a line of output containing just a `#'. 1.1.1.2 root 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, 1.1.1.3 ! root 871: `#pragma' commands are not used, except for `#pragma once' (*note ! 872: Once-Only::.). However, they are left in the preprocessor output, so ! 873: they are available to the compilation pass. 1.1 root 874: 875: The `#ident' command is supported for compatibility with certain 876: other systems. It is followed by a line of text. On some systems, the 1.1.1.2 root 877: text is copied into a special place in the object file; on most systems, 878: the text is ignored and this command has no effect. Typically `#ident' 879: is only used in header files supplied with those systems where it is 880: meaningful. 1.1 root 881: 882: 883: File: cpp.info, Node: Output, Next: Invocation, Prev: Other Commands, Up: Top 884: 885: C Preprocessor Output 886: ===================== 887: 888: The output from the C preprocessor looks much like the input, except 889: that all preprocessor command lines have been replaced with blank lines 890: and all comments with spaces. Whitespace within a line is not altered; 891: however, a space is inserted after the expansions of most macro calls. 892: 893: Source file name and line number information is conveyed by lines of 894: the form 895: 1.1.1.2 root 896: # LINENUM FILENAME FLAGS 1.1 root 897: 898: which are inserted as needed into the middle of the input (but never 899: within a string or character constant). Such a line means that the 900: following line originated in file FILENAME at line LINENUM. 901: 1.1.1.2 root 902: After the file name comes zero or more flags, which are `1', `2' or 903: `3'. If there are multiple flags, spaces separate them. Here is what 904: the flags mean: 905: 906: `1' 907: This indicates the start of a new file. 908: 909: `2' 910: This indicates returning to a file (after having included another 911: file). 912: 913: `3' 914: This indicates that the following text comes from a system header 915: file, so certain warnings should be suppressed. 1.1 root 916: 917: 918: File: cpp.info, Node: Invocation, Next: Concept Index, Prev: Output, Up: Top 919: 920: Invoking the C Preprocessor 921: =========================== 922: 923: Most often when you use the C preprocessor you will not have to 1.1.1.3 ! root 924: invoke it explicitly: the C compiler will do so automatically. 1.1 root 925: However, the preprocessor is sometimes useful individually. 926: 927: The C preprocessor expects two file names as arguments, INFILE and 928: OUTFILE. The preprocessor reads INFILE together with any other files 1.1.1.2 root 929: it specifies with `#include'. All the output generated by the combined 930: input files is written in OUTFILE. 1.1 root 931: 932: Either INFILE or OUTFILE may be `-', which as INFILE means to read 1.1.1.3 ! root 933: from standard input and as OUTFILE means to write to standard output. 1.1 root 934: Also, if OUTFILE or both file names are omitted, the standard output 935: and standard input are used for the omitted file names. 936: 1.1.1.2 root 937: Here is a table of command options accepted by the C preprocessor. 1.1 root 938: These options can also be given when compiling a C program; they are 1.1.1.2 root 939: passed along automatically to the preprocessor when it is invoked by the 940: compiler. 1.1 root 941: 942: `-P' 943: Inhibit generation of `#'-lines with line-number information in 944: the output from the preprocessor (*note Output::.). This might be 945: useful when running the preprocessor on something that is not C 946: code and will be sent to a program which might be confused by the 947: `#'-lines. 948: 949: `-C' 1.1.1.2 root 950: Do not discard comments: pass them through to the output file. 1.1 root 951: Comments appearing in arguments of a macro call will be copied to 952: the output before the expansion of the macro call. 953: 1.1.1.2 root 954: `-traditional' 955: Try to imitate the behavior of old-fashioned C, as opposed to ANSI 956: C. 957: 958: * Traditional macro expansion pays no attention to singlequote 959: or doublequote characters; macro argument symbols are 960: replaced by the argument values even when they appear within 961: apparent string or character constants. 962: 1.1.1.3 ! root 963: * Traditionally, it is permissible for a macro expansion to end 1.1.1.2 root 964: in the middle of a string or character constant. The 965: constant continues into the text surrounding the macro call. 966: 967: * However, traditionally the end of the line terminates a 968: string or character constant, with no error. 969: 1.1.1.3 ! root 970: * In traditional C, a comment is equivalent to no text at all. 1.1.1.2 root 971: (In ANSI C, a comment counts as whitespace.) 972: 973: * Traditional C does not have the concept of a "preprocessing 1.1.1.3 ! root 974: number". It considers `1.0e+4' to be three tokens: `1.0e', 1.1.1.2 root 975: `+', and `4'. 976: 977: * A macro is not suppressed within its own definition, in 1.1.1.3 ! root 978: traditional C. Thus, any macro that is used recursively 1.1.1.2 root 979: inevitably causes an error. 980: 981: * The character `#' has no special meaning within a macro 982: definition in traditional C. 983: 984: * In traditional C, the text at the end of a macro expansion 985: can run together with the text after the macro call, to 1.1.1.3 ! root 986: produce a single token. (This is impossible in ANSI C.) 1.1.1.2 root 987: 988: * Traditionally, `\' inside a macro argument suppresses the 989: syntactic significance of the following character. 990: 1.1 root 991: `-trigraphs' 992: Process ANSI standard trigraph sequences. These are 993: three-character sequences, all starting with `??', that are 994: defined by ANSI C to stand for single characters. For example, 995: `??/' stands for `\', so `'??/n'' is a character constant for a 1.1.1.3 ! root 996: newline. Strictly speaking, the GNU C preprocessor does not 1.1 root 997: support all programs in ANSI Standard C unless `-trigraphs' is 1.1.1.2 root 998: used, but if you ever notice the difference it will be with relief. 1.1 root 999: 1000: You don't want to know any more about trigraphs. 1001: 1002: `-pedantic' 1003: Issue warnings required by the ANSI C standard in certain cases 1.1.1.2 root 1004: such as when text other than a comment follows `#else' or `#endif'. 1.1 root 1005: 1006: `-pedantic-errors' 1007: Like `-pedantic', except that errors are produced rather than 1008: warnings. 1009: 1010: `-Wtrigraphs' 1011: Warn if any trigraphs are encountered (assuming they are enabled). 1012: 1013: `-Wcomment' 1014: Warn whenever a comment-start sequence `/*' appears in a comment. 1015: 1016: `-Wall' 1017: Requests both `-Wtrigraphs' and `-Wcomment' (but not 1018: `-Wtraditional'). 1019: 1020: `-Wtraditional' 1021: Warn about certain constructs that behave differently in 1022: traditional and ANSI C. 1023: 1024: `-I DIRECTORY' 1025: Add the directory DIRECTORY to the end of the list of directories 1.1.1.3 ! root 1026: to be searched for header files (*note Include Syntax::.). This 1.1 root 1027: can be used to override a system header file, substituting your 1.1.1.2 root 1028: own version, since these directories are searched before the system 1029: header file directories. If you use more than one `-I' option, 1030: the directories are scanned in left-to-right order; the standard 1031: system directories come after. 1.1 root 1032: 1033: `-I-' 1034: Any directories specified with `-I' options before the `-I-' 1035: option are searched only for the case of `#include "FILE"'; they 1036: are not searched for `#include <FILE>'. 1037: 1038: If additional directories are specified with `-I' options after 1039: the `-I-', these directories are searched for all `#include' 1.1.1.2 root 1040: commands. 1.1 root 1041: 1042: In addition, the `-I-' option inhibits the use of the current 1.1.1.2 root 1043: directory as the first search directory for `#include "FILE"'. 1.1 root 1044: Therefore, the current directory is searched only if it is 1045: requested explicitly with `-I.'. Specifying both `-I-' and `-I.' 1046: allows you to control precisely which directories are searched 1047: before the current one and which are searched after. 1048: 1049: `-nostdinc' 1.1.1.2 root 1050: Do not search the standard system directories for header files. 1051: Only the directories you have specified with `-I' options (and the 1052: current directory, if appropriate) are searched. 1.1 root 1053: 1054: `-nostdinc++' 1055: Do not search for header files in the C++-specific standard 1.1.1.2 root 1056: directories, but do still search the other standard directories. 1.1.1.3 ! root 1057: (This option is used when building libg++.) 1.1 root 1058: 1059: `-D NAME' 1060: Predefine NAME as a macro, with definition `1'. 1061: 1062: `-D NAME=DEFINITION' 1.1.1.3 ! root 1063: Predefine NAME as a macro, with definition DEFINITION. There are 1.1 root 1064: no restrictions on the contents of DEFINITION, but if you are 1065: invoking the preprocessor from a shell or shell-like program you 1066: may need to use the shell's quoting syntax to protect characters 1067: such as spaces that have a meaning in the shell syntax. If you 1.1.1.2 root 1068: use more than one `-D' for the same NAME, the rightmost definition 1069: takes effect. 1.1 root 1070: 1071: `-U NAME' 1072: Do not predefine NAME. If both `-U' and `-D' are specified for 1073: one name, the `-U' beats the `-D' and the name is not predefined. 1074: 1.1.1.3 ! root 1075: `-undef' ! 1076: Do not predefine any nonstandard macros. ! 1077: 1.1.1.2 root 1078: `-A PREDICATE(ANSWER)' 1.1.1.3 ! root 1079: Make an assertion with the predicate PREDICATE and answer ANSWER. 1.1.1.2 root 1080: *Note Assertions::. 1081: 1082: You can use `-A-' to disable all predefined assertions; it also 1083: undefines all predefined macros that identify the type of target 1084: system. 1.1 root 1085: 1086: `-dM' 1.1.1.2 root 1087: Instead of outputting the result of preprocessing, output a list of 1088: `#define' commands for all the macros defined during the execution 1089: of the preprocessor, including predefined macros. This gives you 1090: a way of finding out what is predefined in your version of the 1091: preprocessor; assuming you have no file `foo.h', the command 1.1 root 1092: 1093: touch foo.h; cpp -dM foo.h 1094: 1095: will show the values of any predefined macros. 1096: 1097: `-dD' 1098: Like `-dM' except in two respects: it does *not* include the 1099: predefined macros, and it outputs *both* the `#define' commands 1100: and the result of preprocessing. Both kinds of output go to the 1101: standard output file. 1102: 1103: `-M' 1104: Instead of outputting the result of preprocessing, output a rule 1.1.1.2 root 1105: suitable for `make' describing the dependencies of the main source 1106: file. The preprocessor outputs one `make' rule containing the 1107: object file name for that source file, a colon, and the names of 1108: all the included files. If there are many included files then the 1109: rule is split into several lines using `\'-newline. 1.1 root 1110: 1111: This feature is used in automatic updating of makefiles. 1112: 1113: `-MM' 1114: Like `-M' but mention only the files included with `#include 1115: "FILE"'. System header files included with `#include <FILE>' are 1116: omitted. 1117: 1118: `-MD' 1119: Like `-M' but the dependency information is written to files with 1120: names made by replacing `.c' with `.d' at the end of the input 1121: file names. This is in addition to compiling the file as 1122: specified--`-MD' does not inhibit ordinary compilation the way 1123: `-M' does. 1124: 1.1.1.2 root 1125: In Mach, you can use the utility `md' to merge the `.d' files into 1126: a single dependency file suitable for using with the `make' 1.1 root 1127: command. 1128: 1129: `-MMD' 1130: Like `-MD' except mention only user header files, not system 1131: header files. 1132: 1133: `-H' 1134: Print the name of each header file used, in addition to other 1135: normal activities. 1136: 1137: `-imacros FILE' 1138: Process FILE as input, discarding the resulting output, before 1139: processing the regular input file. Because the output generated 1140: from FILE is discarded, the only effect of `-imacros FILE' is to 1141: make the macros defined in FILE available for use in the main 1142: input. 1143: 1144: `-include FILE' 1145: Process FILE as input, and include all the resulting output, 1146: before processing the regular input file. 1147: 1.1.1.3 ! root 1148: `-idirafter DIR' ! 1149: Add the directory DIR to the second include path. The directories ! 1150: on the second include path are searched when a header file is not ! 1151: found in any of the directories in the main include path (the one ! 1152: that `-I' adds to). ! 1153: ! 1154: `-iprefix PREFIX' ! 1155: Specify PREFIX as the prefix for subsequent `-iwithprefix' options. ! 1156: ! 1157: `-iwithprefix DIR' ! 1158: Add a directory to the second include path. The directory's name ! 1159: is made by concatenating PREFIX and DIR, where PREFIX was ! 1160: specified previously with `-iprefix'. ! 1161: 1.1 root 1162: `-lang-c' 1163: `-lang-c++' 1164: `-lang-objc' 1165: `-lang-objc++' 1166: Specify the source language. `-lang-c++' makes the preprocessor 1.1.1.3 ! root 1167: handle C++ comment syntax (comments may begin with `//', in which ! 1168: case they end at end of line), and includes extra default include ! 1169: directories for C++; and `-lang-objc' enables the Objective C 1.1.1.2 root 1170: `#import' command. `-lang-c' explicitly turns off both of these 1171: extensions, and `-lang-objc++' enables both. 1.1 root 1172: 1173: These options are generated by the compiler driver `gcc', but not 1174: passed from the `gcc' command line. 1175: 1176: `-lint' 1177: Look for commands to the program checker `lint' embedded in 1178: comments, and emit them preceded by `#pragma lint'. For example, 1179: the comment `/* NOTREACHED */' becomes `#pragma lint NOTREACHED'. 1180: 1181: This option is available only when you call `cpp' directly; `gcc' 1182: will not pass it from its command line. 1183: 1184: `-$' 1185: Forbid the use of `$' in identifiers. This is required for ANSI 1186: conformance. `gcc' automatically supplies this option to the 1187: preprocessor if you specify `-ansi', but `gcc' doesn't recognize 1188: the `-$' option itself--to use it without the other effects of 1189: `-ansi', you must call the preprocessor directly. 1190: 1191: 1192: File: cpp.info, Node: Concept Index, Next: Index, Prev: Invocation, Up: Top 1193: 1194: Concept Index 1195: ************* 1196: 1197: * Menu: 1198: 1.1.1.2 root 1199: * assertions: Assertions. 1200: * assertions, undoing: Assertions. 1.1 root 1201: * cascaded macros: Cascaded Macros. 1202: * commands: Commands. 1203: * concatenation: Concatenation. 1204: * conditionals: Conditionals. 1205: * header file: Header Files. 1206: * inheritance: Inheritance. 1207: * line control: Combining Sources. 1208: * macro body uses macro: Cascaded Macros. 1209: * null command: Other Commands. 1210: * options: Invocation. 1211: * output format: Output. 1212: * overriding a header file: Inheritance. 1213: * predefined macros: Predefined. 1.1.1.2 root 1214: * predicates: Assertions. 1.1 root 1215: * preprocessor commands: Commands. 1216: * redefining macros: Redefining. 1217: * repeated inclusion: Once-Only. 1.1.1.2 root 1218: * retracting assertions: Assertions. 1.1.1.3 ! root 1219: * second include path: Invocation. 1.1 root 1220: * self-reference: Self-Reference. 1221: * semicolons (after macro calls): Swallow Semicolon. 1222: * side effects (in macro arguments): Side Effects. 1223: * stringification: Stringification. 1.1.1.2 root 1224: * testing predicates: Assertions. 1225: * unassert: Assertions. 1.1 root 1226: * undefining macros: Undefining. 1227: * unsafe macros: Side Effects. 1228:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.