![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-6 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-6 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.5 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.5 ! root 6: Published by the Free Software Foundation 675 Massachusetts Avenue ! 7: Cambridge, MA 02139 USA ! 8: ! 9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc. 1.1 root 10: 1.1.1.3 root 11: Permission is granted to make and distribute verbatim copies of this 12: manual provided the copyright notice and this permission notice are 13: preserved on all copies. 1.1 root 14: 15: Permission is granted to copy and distribute modified versions of 16: this manual under the conditions for verbatim copying, provided also 1.1.1.4 root 17: that the sections entitled "GNU General Public License" and "Protect 18: Your Freedom--Fight `Look And Feel'" are included exactly as in the 19: original, and provided that the entire resulting derived work is 20: distributed under the terms of a permission notice identical to this 21: one. 1.1 root 22: 23: Permission is granted to copy and distribute translations of this 24: manual into another language, under the above conditions for modified 1.1.1.3 root 25: versions, except that the sections entitled "GNU General Public 1.1.1.4 root 26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this 27: permission notice, may be included in translations approved by the Free 28: Software Foundation instead of in the original English. 1.1 root 29: 30: 1.1.1.5 ! root 31: File: gcc.info, Node: VMS Install, Next: WE32K Install, Prev: Unos Install, Up: Installation 1.1.1.2 root 32: 1.1.1.5 ! root 33: Installing GNU CC on VMS ! 34: ======================== 1.1.1.2 root 35: 1.1.1.5 ! root 36: The VMS version of GNU CC is distributed in a backup saveset ! 37: containing both source code and precompiled binaries. 1.1.1.2 root 38: 1.1.1.5 ! root 39: To install the `gcc' command so you can use the compiler easily, in ! 40: the same manner as you use the VMS C compiler, you must install the VMS ! 41: CLD file for GNU CC as follows: ! 42: ! 43: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to ! 44: point to the directories where the GNU CC executables ! 45: (`gcc-cpp.exe', `gcc-cc1.exe', etc.) and the C include files are ! 46: kept respectively. This should be done with the commands: ! 47: ! 48: $ assign /system /translation=concealed - ! 49: disk:[gcc.] gnu_cc ! 50: $ assign /system /translation=concealed - ! 51: disk:[gcc.include.] gnu_cc_include ! 52: ! 53: with the appropriate disk and directory names. These commands can ! 54: be placed in your system startup file so they will be executed ! 55: whenever the machine is rebooted. You may, if you choose, do this ! 56: via the `GCC_INSTALL.COM' script in the `[GCC]' directory. ! 57: ! 58: 2. Install the `GCC' command with the command line: ! 59: ! 60: $ set command /table=sys$common:[syslib]dcltables - ! 61: /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc ! 62: $ install replace sys$common:[syslib]dcltables ! 63: ! 64: 3. To install the help file, do the following: ! 65: ! 66: $ library/help sys$library:helplib.hlb gcc.hlp ! 67: ! 68: Now you can invoke the compiler with a command like `gcc /verbose ! 69: file.c', which is equivalent to the command `gcc -v -c file.c' in ! 70: Unix. ! 71: ! 72: If you wish to use GNU C++ you must first install GNU CC, and then ! 73: perform the following steps: ! 74: ! 75: 1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the ! 76: directory where the preprocessor will search for the C++ header ! 77: files. This can be done with the command: ! 78: ! 79: $ assign /system /translation=concealed - ! 80: disk:[gcc.gxx_include.] gnu_gxx_include ! 81: ! 82: with the appropriate disk and directory name. If you are going to ! 83: be using libg++, this is where the libg++ install procedure will ! 84: install the libg++ header files. ! 85: ! 86: 2. Obtain the file `gcc-cc1plus.exe', and place this in the same ! 87: directory that `gcc-cc1.exe' is kept. ! 88: ! 89: The GNU C++ compiler can be invoked with a command like `gcc /plus ! 90: /verbose file.cc', which is equivalent to the command `g++ -v -c ! 91: file.cc' in Unix. ! 92: ! 93: We try to put corresponding binaries and sources on the VMS ! 94: distribution tape. But sometimes the binaries will be from an older ! 95: version than the sources, because we don't always have time to update ! 96: them. (Use the `/version' option to determine the version number of ! 97: the binaries and compare it with the source file `version.c' to tell ! 98: whether this is so.) In this case, you should use the binaries you get ! 99: to recompile the sources. If you must recompile, here is how: ! 100: ! 101: 1. Execute the command procedure `vmsconfig.com' to set up the files ! 102: `tm.h', `config.h', `aux-output.c', and `md.', and to create files ! 103: `tconfig.h' and `hconfig.h'. This procedure also creates several ! 104: linker option files used by `make-cc1.com' and a data file used by ! 105: `make-l2.com'. ! 106: ! 107: $ @vmsconfig.com ! 108: ! 109: 2. Setup the logical names and command tables as defined above. In ! 110: addition, define the VMS logical name `GNU_BISON' to point at the ! 111: to the directories where the Bison executable is kept. This ! 112: should be done with the command: ! 113: ! 114: $ assign /system /translation=concealed - ! 115: disk:[bison.] gnu_bison ! 116: ! 117: You may, if you choose, use the `INSTALL_BISON.COM' script in the ! 118: `[BISON]' directory. ! 119: ! 120: 3. Install the `BISON' command with the command line: ! 121: ! 122: $ set command /table=sys$common:[syslib]dcltables - ! 123: /output=sys$common:[syslib]dcltables - ! 124: gnu_bison:[000000]bison ! 125: $ install replace sys$common:[syslib]dcltables ! 126: ! 127: 4. Type `@make-gcc' to recompile everything (alternatively, submit ! 128: the file `make-gcc.com' to a batch queue). If you wish to build ! 129: the GNU C++ compiler as well as the GNU CC compiler, you must ! 130: first edit `make-gcc.com' and follow the instructions that appear ! 131: in the comments. ! 132: ! 133: 5. In order to use GCC, you need a library of functions which GCC ! 134: compiled code will call to perform certain tasks, and these ! 135: functions are defined in the file `libgcc2.c'. To compile this ! 136: you should use the command procedure `make-l2.com', which will ! 137: generate the library `libgcc2.olb'. `libgcc2.olb' should be built ! 138: using the compiler built from the same distribution that ! 139: `libgcc2.c' came from, and `make-gcc.com' will automatically do ! 140: all of this for you. ! 141: ! 142: To install the library, use the following commands: ! 143: ! 144: $ library gnu_cc:[000000]gcclib/delete=(new,eprintf) ! 145: $ library gnu_cc:[000000]gcclib/delete=L_* ! 146: $ library libgcc2/extract=*/output=libgcc2.obj ! 147: $ library gnu_cc:[000000]gcclib libgcc2.obj ! 148: ! 149: The first command simply removes old modules that will be replaced ! 150: with modules from `libgcc2' under different module names. The ! 151: modules `new' and `eprintf' may not actually be present in your ! 152: `gcclib.olb'--if the VMS librarian complains about those modules ! 153: not being present, simply ignore the message and continue on with ! 154: the next command. The second command removes the modules that ! 155: came from the previous version of the library `libgcc2.c'. ! 156: ! 157: Whenever you update the compiler on your system, you should also ! 158: update the library with the above procedure. ! 159: ! 160: 6. You may wish to build GCC in such a way that no files are written ! 161: to the directory where the source files reside. An example would ! 162: be the when the source files are on a read-only disk. In these ! 163: cases, execute the following DCL commands (substituting your ! 164: actual path names): ! 165: ! 166: $ assign dua0:[gcc.build_dir.]/translation=concealed, - ! 167: dua1:[gcc.source_dir.]/translation=concealed gcc_build ! 168: $ set default gcc_build:[000000] ! 169: ! 170: where the directory `dua1:[gcc.source_dir]' contains the source ! 171: code, and the directory `dua0:[gcc.build_dir]' is meant to contain ! 172: all of the generated object files and executables. Once you have ! 173: done this, you can proceed building GCC as described above. (Keep ! 174: in mind that `gcc_build' is a rooted logical name, and thus the ! 175: device names in each element of the search list must be an actual ! 176: physical device name rather than another rooted logical name). ! 177: ! 178: 7. *If you are building GNU CC with a previous version of GNU CC, you ! 179: also should check to see that you have the newest version of the ! 180: assembler*. In particular, GNU CC version 2 treats global constant ! 181: variables slightly differently from GNU CC version 1, and GAS ! 182: version 1.38.1 does not have the patches required to work with GCC ! 183: version 2. If you use GAS 1.38.1, then `extern const' variables ! 184: will not have the read-only bit set, and the linker will generate ! 185: warning messages about mismatched psect attributes for these ! 186: variables. These warning messages are merely a nuisance, and can ! 187: safely be ignored. 1.1.1.4 root 188: 1.1.1.5 ! root 189: If you are compiling with a version of GNU CC older than 1.33, ! 190: specify `/DEFINE=("inline=")' as an option in all the ! 191: compilations. This requires editing all the `gcc' commands in ! 192: `make-cc1.com'. (The older versions had problems supporting ! 193: `inline'.) Once you have a working 1.33 or newer GNU CC, you can ! 194: change this file back. ! 195: ! 196: 8. If you want to build GNU CC with the VAX C compiler, you will need ! 197: to make minor changes in `make-cccp.com' and `make-cc1.com' to ! 198: choose alternate definitions of `CC', `CFLAGS', and `LIBS'. See ! 199: comments in those files. However, you must also have a working ! 200: version of the GNU assembler (GNU as, aka GAS) as it is used as ! 201: the back-end for GNU CC to produce binary object modules and is ! 202: not included in the GNU CC sources. GAS is also needed to compile ! 203: `libgcc2' in order to build `gcclib' (see above); `make-l2.com' ! 204: expects to be able to find it operational in ! 205: `gnu_cc:[000000]gnu-as.exe'. ! 206: ! 207: To use GNU CC on VMS, you need the VMS driver programs `gcc.exe', ! 208: `gcc.com', and `gcc.cld'. They are distributed with the VMS ! 209: binaries (`gcc-vms') rather than the GNU CC sources. GAS is also ! 210: included in `gcc-vms', as is Bison. ! 211: ! 212: Once you have successfully built GNU CC with VAX C, you should use ! 213: the resulting compiler to rebuild itself. Before doing this, be ! 214: sure to restore the `CC', `CFLAGS', and `LIBS' definitions in ! 215: `make-cccp.com' and `make-cc1.com'. The second generation ! 216: compiler will be able to take advantage of many optimizations that ! 217: must be suppressed when building with other compilers. ! 218: ! 219: Under previous versions of GNU CC, the generated code would ! 220: occasionally give strange results when linked with the sharable ! 221: `VAXCRTL' library. Now this should work. ! 222: ! 223: Even with this version, however, GNU CC itself should not be linked ! 224: with the sharable `VAXCRTL'. The version of `qsort' in `VAXCRTL' has a ! 225: bug (known to be present in VMS versions V4.6 through V5.5) which ! 226: causes the compiler to fail. ! 227: ! 228: The executables are generated by `make-cc1.com' and `make-cccp.com' ! 229: use the object library version of `VAXCRTL' in order to make use of the ! 230: `qsort' routine in `gcclib.olb'. If you wish to link the compiler ! 231: executables with the shareable image version of `VAXCRTL', you should ! 232: edit the file `tm.h' (created by `vmsconfig.com') to define the macro ! 233: `QSORT_WORKAROUND'. ! 234: ! 235: `QSORT_WORKAROUND' is always defined when GNU CC is compiled with ! 236: VAX C, to avoid a problem in case `gcclib.olb' is not yet available. ! 237: ! 238: ! 239: File: gcc.info, Node: WE32K Install, Next: MIPS Install, Prev: VMS Install, Up: Installation ! 240: ! 241: Installing GNU CC on the WE32K ! 242: ============================== ! 243: ! 244: These computers are also known as the 3b2, 3b5, 3b20 and other ! 245: similar names. (However, the 3b1 is actually a 68000; see *Note 3b1 ! 246: Install::.) ! 247: ! 248: Don't use `-g' when compiling with the system's compiler. The ! 249: system's linker seems to be unable to handle such a large program with ! 250: debugging information. ! 251: ! 252: The system's compiler runs out of capacity when compiling `stmt.c' ! 253: in GNU CC. You can work around this by building `cpp' in GNU CC first, ! 254: then use that instead of the system's preprocessor with the system's C ! 255: compiler to compile `stmt.c'. Here is how: ! 256: ! 257: mv /lib/cpp /lib/cpp.att ! 258: cp cpp /lib/cpp.gnu ! 259: echo "/lib/cpp.gnu -traditional $*" > /lib/cpp ! 260: chmod +x /lib/cpp ! 261: ! 262: The system's compiler produces bad code for some of the GNU CC ! 263: optimization files. So you must build the stage 2 compiler without ! 264: optimization. Then build a stage 3 compiler with optimization. That ! 265: executable should work. Here are the necessary commands: ! 266: ! 267: make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g" ! 268: make stage2 ! 269: make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O" ! 270: ! 271: You may need to raise the ULIMIT setting to build a C++ compiler, as ! 272: the file `cc1plus' is larger than one megabyte. ! 273: ! 274: ! 275: File: gcc.info, Node: MIPS Install, Next: Collect2, Prev: WE32K Install, Up: Installation ! 276: ! 277: Installing GNU CC on the MIPS ! 278: ============================= ! 279: ! 280: See *Note Installation:: about whether to use either of the options ! 281: `--with-stabs' or `--with-gnu-as'. ! 282: ! 283: The MIPS C compiler needs to be told to increase its table size for ! 284: switch statements with the `-Wf,-XNg1500' option in order to compile ! 285: `cp-parse.c'. If you use the `-O2' optimization option, you also need ! 286: to use `-Olimit 3000'. Both of these options are automatically ! 287: generated in the `Makefile' that the shell script `configure' builds. ! 288: If you override the `CC' make variable and use the MIPS compilers, you ! 289: may need to add `-Wf,-XNg1500 -Olimit 3000'. ! 290: ! 291: MIPS computers running RISC-OS can support four different ! 292: personalities: default, BSD 4.3, System V.3, and System V.4 (older ! 293: versions of RISC-OS don't support V.4). To configure GCC for these ! 294: platforms use the following configurations: ! 295: ! 296: `mips-mips-riscos`rev'' ! 297: Default configuration for RISC-OS, revision `rev'. ! 298: ! 299: `mips-mips-riscos`rev'bsd' ! 300: BSD 4.3 configuration for RISC-OS, revision `rev'. ! 301: ! 302: `mips-mips-riscos`rev'sysv4' ! 303: System V.4 configuration for RISC-OS, revision `rev'. ! 304: ! 305: `mips-mips-riscos`rev'sysv' ! 306: System V.3 configuration for RISC-OS, revision `rev'. ! 307: ! 308: The revision `rev' mentioned above is the revision of RISC-OS to ! 309: use. You must reconfigure GCC when going from a RISC-OS revision 4 to ! 310: RISC-OS revision 5. This has the effect of avoiding a linker bug (see ! 311: *Note Installation Problems:: for more details). ! 312: ! 313: DECstations can support three different personalities: Ultrix, DEC ! 314: OSF/1, and OSF/rose. To configure GCC for these platforms use the ! 315: following configurations: ! 316: ! 317: `decstation-ultrix' ! 318: Ultrix configuration. ! 319: ! 320: `decstation-osf1' ! 321: Dec's version of OSF/1. ! 322: ! 323: `decstation-osfrose' ! 324: Open Software Foundation reference port of OSF/1 which uses the ! 325: OSF/rose object file format instead of ECOFF. Normally, you would ! 326: not select this configuration. ! 327: ! 328: On Irix version 4.0.5F, and perhaps on some other versions as well, ! 329: there is an assembler bug that reorders instructions incorrectly. To ! 330: work around it, specify the target configuration `mips-sgi-irix4loser'. ! 331: This configuration inhibits assembler optimization. ! 332: ! 333: You can turn off assembler optimization in a compiler configured with ! 334: target `mips-sgi-irix4' using the `-noasmopt' option. This compiler ! 335: option passes the option `-O0' to the assembler, to inhibit reordering. ! 336: ! 337: The `-noasmopt' option can be useful for testing whether a problem ! 338: is due to erroneous assembler reordering. Even if a problem does not go ! 339: away with `-noasmopt', it may still be due to assembler ! 340: reordering--perhaps GNU CC itself was miscompiled as a result. ! 341: ! 342: We know this is inconvenient, but it's the best that can be done at ! 343: the last minute. ! 344: ! 345: ! 346: File: gcc.info, Node: Collect2, Prev: MIPS Install, Up: Installation ! 347: ! 348: `collect2' ! 349: ========== ! 350: ! 351: Many target systems do not have support in the assembler and linker ! 352: for "constructors"--initialization functions to be called before the ! 353: official "start" of `main'. On such systems, GNU CC uses a utility ! 354: called `collect2' to arrange to call these functions at start time. ! 355: ! 356: The program `collect2' works by linking the program once and looking ! 357: through the linker output file for symbols with particular names ! 358: indicating they are constructor functions. If it finds any, it creates ! 359: a new temporary `.c' file containing a table of them, compiles it, and ! 360: links the program a second time including that file. ! 361: ! 362: The actual calls to the constructors are carried out by a subroutine ! 363: called `__main', which is called (automatically) at the beginning of ! 364: the body of `main' (provided `main' was compiled with GNU CC). ! 365: ! 366: The program `collect2' is installed as `ld' in the directory where ! 367: the passes of the compiler are installed. When `collect2' needs to ! 368: find the *real* `ld', it tries the following file names: ! 369: ! 370: * `gld' in the directories listed in the compiler's search ! 371: directories. ! 372: ! 373: * `gld' in the directories listed in the environment variable `PATH'. ! 374: ! 375: * `real-ld' in the compiler's search directories. ! 376: ! 377: * `real-ld' in `PATH'. ! 378: ! 379: * `ld' in `PATH'. ! 380: ! 381: "The compiler's search directories" means all the directories where ! 382: `gcc' searches for passes of the compiler. This includes directories ! 383: that you specify with `-B'. ! 384: ! 385: Cross compilers search a little differently: ! 386: ! 387: * `gld' in the compiler's search directories. ! 388: ! 389: * `TARGET-gld' in `PATH'. ! 390: ! 391: * `real-ld' in the compiler's search directories. ! 392: ! 393: * `TARGET-real-ld' in `PATH'. ! 394: ! 395: * `TARGET-ld' in `PATH'. ! 396: ! 397: `collect2' does not search for `ld' using the compiler's search ! 398: directories, because if it did, it would find itself--not the real ! 399: `ld'--and this could lead to infinite recursion. However, the ! 400: directory where `collect2' is installed might happen to be in `PATH'. ! 401: That could lead `collect2' to invoke itself anyway. when looking for ! 402: `ld'. ! 403: ! 404: To prevent this, `collect2' explicitly avoids running `ld' using the ! 405: file name under which `collect2' itself was invoked. In fact, it ! 406: remembers up to two such names--in case one copy of `collect2' finds ! 407: another copy (or version) of `collect2' installed as `ld' in a second ! 408: place in the search path. ! 409: ! 410: If two file names to avoid are not sufficient, you may still ! 411: encounter an infinite recursion of `collect2' processes. When this ! 412: happens. check all the files installed as `ld' in any of the ! 413: directories searched, and straighten out the situation. ! 414: ! 415: (In a future version, we will probably change `collect2' to avoid ! 416: any reinvocation of a file from which any parent `collect2' was run.) ! 417: ! 418: ! 419: File: gcc.info, Node: C Extensions, Next: C++ Extensions, Prev: Installation, Up: Top ! 420: ! 421: Extensions to the C Language Family ! 422: *********************************** ! 423: ! 424: GNU C provides several language features not found in ANSI standard ! 425: C. (The `-pedantic' option directs GNU CC to print a warning message if ! 426: any of these features is used.) To test for the availability of these ! 427: features in conditional compilation, check for a predefined macro ! 428: `__GNUC__', which is always defined under GNU CC. ! 429: ! 430: These extensions are available in C and in the languages derived from ! 431: it, C++ and Objective C. *Note Extensions to the C++ Language: C++ ! 432: Extensions, for extensions that apply *only* to C++. ! 433: ! 434: * Menu: ! 435: ! 436: * Statement Exprs:: Putting statements and declarations inside expressions. ! 437: * Local Labels:: Labels local to a statement-expression. ! 438: * Labels as Values:: Getting pointers to labels, and computed gotos. ! 439: * Nested Functions:: As in Algol and Pascal, lexical scoping of functions. ! 440: * Constructing Calls:: Dispatching a call to another function. ! 441: * Naming Types:: Giving a name to the type of some expression. ! 442: * Typeof:: `typeof': referring to the type of an expression. ! 443: * Lvalues:: Using `?:', `,' and casts in lvalues. ! 444: * Conditionals:: Omitting the middle operand of a `?:' expression. ! 445: * Long Long:: Double-word integers--`long long int'. ! 446: * Zero Length:: Zero-length arrays. ! 447: * Variable Length:: Arrays whose length is computed at run time. ! 448: * Macro Varargs:: Macros with variable number of arguments. ! 449: * Subscripting:: Any array can be subscripted, even if not an lvalue. ! 450: * Pointer Arith:: Arithmetic on `void'-pointers and function pointers. ! 451: * Initializers:: Non-constant initializers. ! 452: * Constructors:: Constructor expressions give structures, unions ! 453: or arrays as values. ! 454: * Labeled Elements:: Labeling elements of initializers. ! 455: * Cast to Union:: Casting to union type from any member of the union. ! 456: * Case Ranges:: `case 1 ... 9' and such. ! 457: * Function Attributes:: Declaring that functions have no side effects, ! 458: or that they can never return. ! 459: * Function Prototypes:: Prototype declarations and old-style definitions. ! 460: * Dollar Signs:: Dollar sign is allowed in identifiers. ! 461: * Character Escapes:: `\e' stands for the character ESC. ! 462: * Variable Attributes:: Specifying attributes of variables. ! 463: * Alignment:: Inquiring about the alignment of a type or variable. ! 464: * Inline:: Defining inline functions (as fast as macros). ! 465: * Extended Asm:: Assembler instructions with C expressions as operands. ! 466: (With them you can define "built-in" functions.) ! 467: * Asm Labels:: Specifying the assembler name to use for a C symbol. ! 468: * Explicit Reg Vars:: Defining variables residing in specified registers. ! 469: * Alternate Keywords:: `__const__', `__asm__', etc., for header files. ! 470: * Incomplete Enums:: `enum foo;', with details to follow. ! 471: * Function Names:: Printable strings which are the name of the current ! 472: function. ! 473: ! 474: ! 475: File: gcc.info, Node: Statement Exprs, Next: Local Labels, Up: C Extensions ! 476: ! 477: Statements and Declarations in Expressions ! 478: ========================================== 1.1.1.4 root 479: 1.1.1.5 ! root 480: A compound statement enclosed in parentheses may appear as an ! 481: expression in GNU C. This allows you to use loops, switches, and local ! 482: variables within an expression. ! 483: ! 484: Recall that a compound statement is a sequence of statements ! 485: surrounded by braces; in this construct, parentheses go around the ! 486: braces. For example: ! 487: ! 488: ({ int y = foo (); int z; ! 489: if (y > 0) z = y; ! 490: else z = - y; ! 491: z; }) ! 492: ! 493: is a valid (though slightly more complex than necessary) expression for ! 494: the absolute value of `foo ()'. ! 495: ! 496: The last thing in the compound statement should be an expression ! 497: followed by a semicolon; the value of this subexpression serves as the ! 498: value of the entire construct. (If you use some other kind of statement ! 499: last within the braces, the construct has type `void', and thus ! 500: effectively no value.) ! 501: ! 502: This feature is especially useful in making macro definitions "safe" ! 503: (so that they evaluate each operand exactly once). For example, the ! 504: "maximum" function is commonly defined as a macro in standard C as ! 505: follows: ! 506: ! 507: #define max(a,b) ((a) > (b) ? (a) : (b)) ! 508: ! 509: But this definition computes either A or B twice, with bad results if ! 510: the operand has side effects. In GNU C, if you know the type of the ! 511: operands (here let's assume `int'), you can define the macro safely as ! 512: follows: ! 513: ! 514: #define maxint(a,b) \ ! 515: ({int _a = (a), _b = (b); _a > _b ? _a : _b; }) ! 516: ! 517: Embedded statements are not allowed in constant expressions, such as ! 518: the value of an enumeration constant, the width of a bit field, or the ! 519: initial value of a static variable. ! 520: ! 521: If you don't know the type of the operand, you can still do this, ! 522: but you must use `typeof' (*note Typeof::.) or type naming (*note ! 523: Naming Types::.). 1.1.1.2 root 524: 1.1.1.4 root 525: 1.1.1.5 ! root 526: File: gcc.info, Node: Local Labels, Next: Labels as Values, Prev: Statement Exprs, Up: C Extensions 1.1.1.2 root 527: 1.1.1.5 ! root 528: Locally Declared Labels ! 529: ======================= ! 530: ! 531: Each statement expression is a scope in which "local labels" can be ! 532: declared. A local label is simply an identifier; you can jump to it ! 533: with an ordinary `goto' statement, but only from within the statement ! 534: expression it belongs to. ! 535: ! 536: A local label declaration looks like this: ! 537: ! 538: __label__ LABEL; ! 539: ! 540: or ! 541: ! 542: __label__ LABEL1, LABEL2, ...; ! 543: ! 544: Local label declarations must come at the beginning of the statement ! 545: expression, right after the `({', before any ordinary declarations. 1.1.1.2 root 546: 1.1.1.5 ! root 547: The label declaration defines the label *name*, but does not define ! 548: the label itself. You must do this in the usual way, with `LABEL:', ! 549: within the statements of the statement expression. ! 550: ! 551: The local label feature is useful because statement expressions are ! 552: often used in macros. If the macro contains nested loops, a `goto' can ! 553: be useful for breaking out of them. However, an ordinary label whose ! 554: scope is the whole function cannot be used: if the macro can be ! 555: expanded several times in one function, the label will be multiply ! 556: defined in that function. A local label avoids this problem. For 1.1.1.4 root 557: example: 558: 1.1.1.5 ! root 559: #define SEARCH(array, target) \ ! 560: ({ \ ! 561: __label__ found; \ ! 562: typeof (target) _SEARCH_target = (target); \ ! 563: typeof (*(array)) *_SEARCH_array = (array); \ ! 564: int i, j; \ ! 565: int value; \ ! 566: for (i = 0; i < max; i++) \ ! 567: for (j = 0; j < max; j++) \ ! 568: if (_SEARCH_array[i][j] == _SEARCH_target) \ ! 569: { value = i; goto found; } \ ! 570: value = -1; \ ! 571: found: \ ! 572: value; \ ! 573: }) ! 574: ! 575: ! 576: File: gcc.info, Node: Labels as Values, Next: Nested Functions, Prev: Local Labels, Up: C Extensions ! 577: ! 578: Labels as Values ! 579: ================ ! 580: ! 581: You can get the address of a label defined in the current function ! 582: (or a containing function) with the unary operator `&&'. The value has ! 583: type `void *'. This value is a constant and can be used wherever a ! 584: constant of that type is valid. For example: ! 585: ! 586: void *ptr; ! 587: ... ! 588: ptr = &&foo; ! 589: ! 590: To use these values, you need to be able to jump to one. This is ! 591: done with the computed goto statement(1), `goto *EXP;'. For example, ! 592: ! 593: goto *ptr; ! 594: ! 595: Any expression of type `void *' is allowed. ! 596: ! 597: One way of using these constants is in initializing a static array ! 598: that will serve as a jump table: ! 599: ! 600: static void *array[] = { &&foo, &&bar, &&hack }; ! 601: ! 602: Then you can select a label with indexing, like this: ! 603: ! 604: goto *array[i]; ! 605: ! 606: Note that this does not check whether the subscript is in bounds--array ! 607: indexing in C never does that. ! 608: ! 609: Such an array of label values serves a purpose much like that of the ! 610: `switch' statement. The `switch' statement is cleaner, so use that ! 611: rather than an array unless the problem does not fit a `switch' ! 612: statement very well. ! 613: ! 614: Another use of label values is in an interpreter for threaded code. ! 615: The labels within the interpreter function can be stored in the ! 616: threaded code for super-fast dispatching. ! 617: ! 618: You can use this mechanism to jump to code in a different function. ! 619: If you do that, totally unpredictable things will happen. The best way ! 620: to avoid this is to store the label address only in automatic variables ! 621: and never pass it as an argument. ! 622: ! 623: ---------- Footnotes ---------- ! 624: ! 625: (1) The analogous feature in Fortran is called an assigned goto, ! 626: but that name seems inappropriate in C, where one can do more than ! 627: simply store label addresses in label variables. ! 628: ! 629: ! 630: File: gcc.info, Node: Nested Functions, Next: Constructing Calls, Prev: Labels as Values, Up: C Extensions ! 631: ! 632: Nested Functions ! 633: ================ ! 634: ! 635: A "nested function" is a function defined inside another function. ! 636: (Nested functions are not supported for GNU C++.) The nested function's ! 637: name is local to the block where it is defined. For example, here we ! 638: define a nested function named `square', and call it twice: ! 639: ! 640: foo (double a, double b) ! 641: { ! 642: double square (double z) { return z * z; } 1.1.1.4 root 643: 1.1.1.5 ! root 644: return square (a) + square (b); ! 645: } ! 646: ! 647: The nested function can access all the variables of the containing ! 648: function that are visible at the point of its definition. This is ! 649: called "lexical scoping". For example, here we show a nested function ! 650: which uses an inherited variable named `offset': ! 651: ! 652: bar (int *array, int offset, int size) ! 653: { ! 654: int access (int *array, int index) ! 655: { return array[index + offset]; } ! 656: int i; ! 657: ... ! 658: for (i = 0; i < size; i++) ! 659: ... access (array, i) ... ! 660: } ! 661: ! 662: Nested function definitions are permitted within functions in the ! 663: places where variable definitions are allowed; that is, in any block, ! 664: before the first statement in the block. ! 665: ! 666: It is possible to call the nested function from outside the scope of ! 667: its name by storing its address or passing the address to another ! 668: function: ! 669: ! 670: hack (int *array, int size) 1.1.1.4 root 671: { 1.1.1.5 ! root 672: void store (int index, int value) ! 673: { array[index] = value; } ! 674: ! 675: intermediate (store, size); 1.1.1.4 root 676: } 677: 1.1.1.5 ! root 678: Here, the function `intermediate' receives the address of `store' as ! 679: an argument. If `intermediate' calls `store', the arguments given to ! 680: `store' are used to store into `array'. But this technique works only ! 681: so long as the containing function (`hack', in this example) does not ! 682: exit. If you try to call the nested function through its address after ! 683: the containing function has exited, all hell will break loose. ! 684: ! 685: GNU CC implements taking the address of a nested function using a ! 686: technique called "trampolines". A paper describing them is available ! 687: from `maya.idiap.ch' in directory `pub/tmb', file `usenix88-lexic.ps.Z'. ! 688: ! 689: A nested function can jump to a label inherited from a containing ! 690: function, provided the label was explicitly declared in the containing ! 691: function (*note Local Labels::.). Such a jump returns instantly to the ! 692: containing function, exiting the nested function which did the `goto' ! 693: and any intermediate functions as well. Here is an example: 1.1.1.4 root 694: 1.1.1.5 ! root 695: bar (int *array, int offset, int size) ! 696: { ! 697: __label__ failure; ! 698: int access (int *array, int index) ! 699: { ! 700: if (index > size) ! 701: goto failure; ! 702: return array[index + offset]; ! 703: } ! 704: int i; ! 705: ... ! 706: for (i = 0; i < size; i++) ! 707: ... access (array, i) ... ! 708: ... ! 709: return 0; 1.1.1.4 root 710: 1.1.1.5 ! root 711: /* Control comes here from `access' ! 712: if it detects an error. */ ! 713: failure: ! 714: return -1; ! 715: } ! 716: ! 717: A nested function always has internal linkage. Declaring one with ! 718: `extern' is erroneous. If you need to declare the nested function ! 719: before its definition, use `auto' (which is otherwise meaningless for ! 720: function declarations). ! 721: ! 722: bar (int *array, int offset, int size) 1.1.1.4 root 723: { 1.1.1.5 ! root 724: __label__ failure; ! 725: auto int access (int *, int); ! 726: ... ! 727: int access (int *array, int index) ! 728: { ! 729: if (index > size) ! 730: goto failure; ! 731: return array[index + offset]; ! 732: } ! 733: ... 1.1.1.4 root 734: } 1.1.1.2 root 735: 736: 1.1.1.5 ! root 737: File: gcc.info, Node: Constructing Calls, Next: Naming Types, Prev: Nested Functions, Up: C Extensions 1.1 root 738: 1.1.1.5 ! root 739: Constructing Function Calls ! 740: =========================== 1.1 root 741: 1.1.1.5 ! root 742: Using the built-in functions described below, you can record the ! 743: arguments a function received, and call another function with the same ! 744: arguments, without knowing the number or types of the arguments. ! 745: ! 746: You can also record the return value of that function call, and ! 747: later return that value, without knowing what data type the function ! 748: tried to return (as long as your caller expects that data type). ! 749: ! 750: `__builtin_apply_args ()' ! 751: This built-in function returns a pointer of type `void *' to data ! 752: describing how to perform a call with the same arguments as were ! 753: passed to the current function. ! 754: ! 755: The function saves the arg pointer register, structure value ! 756: address, and all registers that might be used to pass arguments to ! 757: a function into a block of memory allocated on the stack. Then it ! 758: returns the address of that block. ! 759: ! 760: `__builtin_apply (FUNCTION, ARGUMENTS, SIZE)' ! 761: This built-in function invokes FUNCTION (type `void (*)()') with a ! 762: copy of the parameters described by ARGUMENTS (type `void *') and ! 763: SIZE (type `int'). ! 764: ! 765: The value of ARGUMENTS should be the value returned by ! 766: `__builtin_apply_args'. The argument SIZE specifies the size of ! 767: the stack argument data, in bytes. ! 768: ! 769: This function returns a pointer of type `void *' to data describing ! 770: how to return whatever value was returned by FUNCTION. The data ! 771: is saved in a block of memory allocated on the stack. ! 772: ! 773: It is not always simple to compute the proper value for SIZE. The ! 774: value is used by `__builtin_apply' to compute the amount of data ! 775: that should be pushed on the stack and copied from the incoming ! 776: argument area. ! 777: ! 778: `__builtin_return (RESULT)' ! 779: This built-in function returns the value described by RESULT from ! 780: the containing function. You should specify, for RESULT, a value ! 781: returned by `__builtin_apply'. 1.1.1.3 root 782: 1.1.1.5 ! root 783: ! 784: File: gcc.info, Node: Naming Types, Next: Typeof, Prev: Constructing Calls, Up: C Extensions 1.1.1.4 root 785: 1.1.1.5 ! root 786: Naming an Expression's Type ! 787: =========================== 1.1.1.4 root 788: 1.1.1.5 ! root 789: You can give a name to the type of an expression using a `typedef' ! 790: declaration with an initializer. Here is how to define NAME as a type ! 791: name for the type of EXP: ! 792: ! 793: typedef NAME = EXP; ! 794: ! 795: This is useful in conjunction with the statements-within-expressions ! 796: feature. Here is how the two together can be used to define a safe ! 797: "maximum" macro that operates on any arithmetic type: ! 798: ! 799: #define max(a,b) \ ! 800: ({typedef _ta = (a), _tb = (b); \ ! 801: _ta _a = (a); _tb _b = (b); \ ! 802: _a > _b ? _a : _b; }) ! 803: ! 804: The reason for using names that start with underscores for the local ! 805: variables is to avoid conflicts with variable names that occur within ! 806: the expressions that are substituted for `a' and `b'. Eventually we ! 807: hope to design a new form of declaration syntax that allows you to ! 808: declare variables whose scopes start only after their initializers; ! 809: this will be a more reliable way to prevent such conflicts. 1.1.1.3 root 810: 811: 1.1.1.5 ! root 812: File: gcc.info, Node: Typeof, Next: Lvalues, Prev: Naming Types, Up: C Extensions 1.1.1.3 root 813: 1.1.1.5 ! root 814: Referring to a Type with `typeof' ! 815: ================================= ! 816: ! 817: Another way to refer to the type of an expression is with `typeof'. ! 818: The syntax of using of this keyword looks like `sizeof', but the ! 819: construct acts semantically like a type name defined with `typedef'. ! 820: ! 821: There are two ways of writing the argument to `typeof': with an ! 822: expression or with a type. Here is an example with an expression: 1.1.1.3 root 823: 1.1.1.5 ! root 824: typeof (x[0](1)) ! 825: ! 826: This assumes that `x' is an array of functions; the type described is ! 827: that of the values of the functions. ! 828: ! 829: Here is an example with a typename as the argument: ! 830: ! 831: typeof (int *) ! 832: ! 833: Here the type described is that of pointers to `int'. ! 834: ! 835: If you are writing a header file that must work when included in ! 836: ANSI C programs, write `__typeof__' instead of `typeof'. *Note ! 837: Alternate Keywords::. ! 838: ! 839: A `typeof'-construct can be used anywhere a typedef name could be ! 840: used. For example, you can use it in a declaration, in a cast, or ! 841: inside of `sizeof' or `typeof'. ! 842: ! 843: * This declares `y' with the type of what `x' points to. ! 844: ! 845: typeof (*x) y; ! 846: ! 847: * This declares `y' as an array of such values. ! 848: ! 849: typeof (*x) y[4]; ! 850: ! 851: * This declares `y' as an array of pointers to characters: ! 852: ! 853: typeof (typeof (char *)[4]) y; ! 854: ! 855: It is equivalent to the following traditional C declaration: ! 856: ! 857: char *y[4]; ! 858: ! 859: To see the meaning of the declaration using `typeof', and why it ! 860: might be a useful way to write, let's rewrite it with these macros: ! 861: ! 862: #define pointer(T) typeof(T *) ! 863: #define array(T, N) typeof(T [N]) ! 864: ! 865: Now the declaration can be rewritten this way: ! 866: ! 867: array (pointer (char), 4) y; ! 868: ! 869: Thus, `array (pointer (char), 4)' is the type of arrays of 4 ! 870: pointers to `char'. 1.1.1.3 root 871: 1.1.1.4 root 872: 1.1.1.5 ! root 873: File: gcc.info, Node: Lvalues, Next: Conditionals, Prev: Typeof, Up: C Extensions ! 874: ! 875: Generalized Lvalues ! 876: =================== ! 877: ! 878: Compound expressions, conditional expressions and casts are allowed ! 879: as lvalues provided their operands are lvalues. This means that you ! 880: can take their addresses or store values into them. ! 881: ! 882: For example, a compound expression can be assigned, provided the last ! 883: expression in the sequence is an lvalue. These two expressions are ! 884: equivalent: ! 885: ! 886: (a, b) += 5 ! 887: a, (b += 5) ! 888: ! 889: Similarly, the address of the compound expression can be taken. ! 890: These two expressions are equivalent: ! 891: ! 892: &(a, b) ! 893: a, &b ! 894: ! 895: A conditional expression is a valid lvalue if its type is not void ! 896: and the true and false branches are both valid lvalues. For example, ! 897: these two expressions are equivalent: ! 898: ! 899: (a ? b : c) = 5 ! 900: (a ? b = 5 : (c = 5)) 1.1.1.3 root 901: 1.1.1.5 ! root 902: A cast is a valid lvalue if its operand is an lvalue. A simple ! 903: assignment whose left-hand side is a cast works by converting the ! 904: right-hand side first to the specified type, then to the type of the ! 905: inner left-hand side expression. After this is stored, the value is ! 906: converted back to the specified type to become the value of the ! 907: assignment. Thus, if `a' has type `char *', the following two ! 908: expressions are equivalent: 1.1.1.3 root 909: 1.1.1.5 ! root 910: (int)a = 5 ! 911: (int)(a = (char *)(int)5) 1.1.1.4 root 912: 1.1.1.5 ! root 913: An assignment-with-arithmetic operation such as `+=' applied to a ! 914: cast performs the arithmetic using the type resulting from the cast, ! 915: and then continues as in the previous case. Therefore, these two ! 916: expressions are equivalent: 1.1.1.4 root 917: 1.1.1.5 ! root 918: (int)a += 5 ! 919: (int)(a = (char *)(int) ((int)a + 5)) 1.1.1.4 root 920: 1.1.1.5 ! root 921: You cannot take the address of an lvalue cast, because the use of its ! 922: address would not work out coherently. Suppose that `&(int)f' were ! 923: permitted, where `f' has type `float'. Then the following statement ! 924: would try to store an integer bit-pattern where a floating point number ! 925: belongs: 1.1.1.4 root 926: 1.1.1.5 ! root 927: *&(int)f = 1; 1.1.1.4 root 928: 1.1.1.5 ! root 929: This is quite different from what `(int)f = 1' would do--that would ! 930: convert 1 to floating point and store it. Rather than cause this ! 931: inconsistency, we think it is better to prohibit use of `&' on a cast. 1.1.1.3 root 932: 1.1.1.5 ! root 933: If you really do want an `int *' pointer with the address of `f', ! 934: you can simply write `(int *)&f'. 1.1.1.3 root 935: 936: 1.1.1.5 ! root 937: File: gcc.info, Node: Conditionals, Next: Long Long, Prev: Lvalues, Up: C Extensions 1.1.1.3 root 938: 1.1.1.5 ! root 939: Conditionals with Omitted Operands 1.1.1.4 root 940: ================================== 1.1.1.3 root 941: 1.1.1.5 ! root 942: The middle operand in a conditional expression may be omitted. Then ! 943: if the first operand is nonzero, its value is the value of the ! 944: conditional expression. 1.1.1.4 root 945: 1.1.1.5 ! root 946: Therefore, the expression 1.1.1.4 root 947: 1.1.1.5 ! root 948: x ? : y ! 949: ! 950: has the value of `x' if that is nonzero; otherwise, the value of `y'. ! 951: ! 952: This example is perfectly equivalent to ! 953: ! 954: x ? x : y ! 955: ! 956: In this simple case, the ability to omit the middle operand is not ! 957: especially useful. When it becomes useful is when the first operand ! 958: does, or may (if it is a macro argument), contain a side effect. Then ! 959: repeating the operand in the middle would perform the side effect ! 960: twice. Omitting the middle operand uses the value already computed ! 961: without the undesirable effects of recomputing it. ! 962: ! 963: ! 964: File: gcc.info, Node: Long Long, Next: Zero Length, Prev: Conditionals, Up: C Extensions ! 965: ! 966: Double-Word Integers ! 967: ==================== ! 968: ! 969: GNU C supports data types for integers that are twice as long as ! 970: `long int'. Simply write `long long int' for a signed integer, or ! 971: `unsigned long long int' for an unsigned integer. To make an integer ! 972: constant of type `long long int', add the suffix `LL' to the integer. ! 973: To make an integer constant of type `unsigned long long int', add the ! 974: suffix `ULL' to the integer. ! 975: ! 976: You can use these types in arithmetic like any other integer types. ! 977: Addition, subtraction, and bitwise boolean operations on these types ! 978: are open-coded on all types of machines. Multiplication is open-coded ! 979: if the machine supports fullword-to-doubleword a widening multiply ! 980: instruction. Division and shifts are open-coded only on machines that ! 981: provide special support. The operations that are not open-coded use ! 982: special library routines that come with GNU CC. ! 983: ! 984: There may be pitfalls when you use `long long' types for function ! 985: arguments, unless you declare function prototypes. If a function ! 986: expects type `int' for its argument, and you pass a value of type `long ! 987: long int', confusion will result because the caller and the subroutine ! 988: will disagree about the number of bytes for the argument. Likewise, if ! 989: the function expects `long long int' and you pass `int'. The best way ! 990: to avoid such problems is to use prototypes. ! 991: ! 992: ! 993: File: gcc.info, Node: Zero Length, Next: Variable Length, Prev: Long Long, Up: C Extensions ! 994: ! 995: Arrays of Length Zero ! 996: ===================== ! 997: ! 998: Zero-length arrays are allowed in GNU C. They are very useful as ! 999: the last element of a structure which is really a header for a ! 1000: variable-length object: ! 1001: ! 1002: struct line { ! 1003: int length; ! 1004: char contents[0]; ! 1005: }; ! 1006: 1.1.1.4 root 1007: { 1.1.1.5 ! root 1008: struct line *thisline = (struct line *) ! 1009: malloc (sizeof (struct line) + this_length); ! 1010: thisline->length = this_length; 1.1.1.4 root 1011: } 1012: 1.1.1.5 ! root 1013: In standard C, you would have to give `contents' a length of 1, which ! 1014: means either you waste space or complicate the argument to `malloc'. 1.1.1.4 root 1015: 1.1.1.5 ! root 1016: ! 1017: File: gcc.info, Node: Variable Length, Next: Macro Varargs, Prev: Zero Length, Up: C Extensions 1.1.1.4 root 1018: 1.1.1.5 ! root 1019: Arrays of Variable Length ! 1020: ========================= 1.1.1.4 root 1021: 1.1.1.5 ! root 1022: Variable-length automatic arrays are allowed in GNU C. These arrays ! 1023: are declared like any other automatic arrays, but with a length that is ! 1024: not a constant expression. The storage is allocated at the point of ! 1025: declaration and deallocated when the brace-level is exited. For ! 1026: example: ! 1027: ! 1028: FILE * ! 1029: concat_fopen (char *s1, char *s2, char *mode) ! 1030: { ! 1031: char str[strlen (s1) + strlen (s2) + 1]; ! 1032: strcpy (str, s1); ! 1033: strcat (str, s2); ! 1034: return fopen (str, mode); ! 1035: } ! 1036: ! 1037: Jumping or breaking out of the scope of the array name deallocates ! 1038: the storage. Jumping into the scope is not allowed; you get an error ! 1039: message for it. ! 1040: ! 1041: You can use the function `alloca' to get an effect much like ! 1042: variable-length arrays. The function `alloca' is available in many ! 1043: other C implementations (but not in all). On the other hand, ! 1044: variable-length arrays are more elegant. ! 1045: ! 1046: There are other differences between these two methods. Space ! 1047: allocated with `alloca' exists until the containing *function* returns. ! 1048: The space for a variable-length array is deallocated as soon as the ! 1049: array name's scope ends. (If you use both variable-length arrays and ! 1050: `alloca' in the same function, deallocation of a variable-length array ! 1051: will also deallocate anything more recently allocated with `alloca'.) ! 1052: ! 1053: You can also use variable-length arrays as arguments to functions: ! 1054: ! 1055: struct entry ! 1056: tester (int len, char data[len][len]) ! 1057: { ! 1058: ... ! 1059: } ! 1060: ! 1061: The length of an array is computed once when the storage is allocated ! 1062: and is remembered for the scope of the array in case you access it with ! 1063: `sizeof'. ! 1064: ! 1065: If you want to pass the array first and the length afterward, you can ! 1066: use a forward declaration in the parameter list--another GNU extension. ! 1067: ! 1068: struct entry ! 1069: tester (int len; char data[len][len], int len) ! 1070: { ! 1071: ... ! 1072: } ! 1073: ! 1074: The `int len' before the semicolon is a "parameter forward ! 1075: declaration", and it serves the purpose of making the name `len' known ! 1076: when the declaration of `data' is parsed. ! 1077: ! 1078: You can write any number of such parameter forward declarations in ! 1079: the parameter list. They can be separated by commas or semicolons, but ! 1080: the last one must end with a semicolon, which is followed by the "real" ! 1081: parameter declarations. Each forward declaration must match a "real" ! 1082: declaration in parameter name and data type. 1.1.1.3 root 1083: 1.1.1.4 root 1084: 1.1.1.5 ! root 1085: File: gcc.info, Node: Macro Varargs, Next: Subscripting, Prev: Variable Length, Up: C Extensions 1.1.1.3 root 1086: 1.1.1.5 ! root 1087: Macros with Variable Numbers of Arguments ! 1088: ========================================= 1.1.1.3 root 1089: 1.1.1.5 ! root 1090: In GNU C, a macro can accept a variable number of arguments, much as ! 1091: a function can. The syntax for defining the macro looks much like that ! 1092: used for a function. Here is an example: ! 1093: ! 1094: #define eprintf(format, args...) \ ! 1095: fprintf (stderr, format , ## args) ! 1096: ! 1097: Here `args' is a "rest argument": it takes in zero or more ! 1098: arguments, as many as the call contains. All of them plus the commas ! 1099: between them form the value of `args', which is substituted into the ! 1100: macro body where `args' is used. Thus, we have this expansion: ! 1101: ! 1102: eprintf ("%s:%d: ", input_file_name, line_number) ! 1103: ==> ! 1104: fprintf (stderr, "%s:%d: " , input_file_name, line_number) ! 1105: ! 1106: Note that the comma after the string constant comes from the definition ! 1107: of `eprintf', whereas the last comma comes from the value of `args'. ! 1108: ! 1109: The reason for using `##' is to handle the case when `args' matches ! 1110: no arguments at all. In this case, `args' has an empty value. In this ! 1111: case, the second comma in the definition becomes an embarrassment: if ! 1112: it got through to the expansion of the macro, we would get something ! 1113: like this: 1.1.1.3 root 1114: 1.1.1.5 ! root 1115: fprintf (stderr, "success!\n" , ) ! 1116: ! 1117: which is invalid C syntax. `##' gets rid of the comma, so we get the ! 1118: following instead: 1.1.1.3 root 1119: 1.1.1.5 ! root 1120: fprintf (stderr, "success!\n") ! 1121: ! 1122: This is a special feature of the GNU C preprocessor: `##' before a ! 1123: rest argument that is empty discards the preceding sequence of ! 1124: non-whitespace characters from the macro definition. (If another macro ! 1125: argument precedes, none of it is discarded.) ! 1126: ! 1127: It might be better to discard the last preprocessor token instead of ! 1128: the last preceding sequence of non-whitespace characters; in fact, we ! 1129: may someday change this feature to do so. We advise you to write the ! 1130: macro definition so that the preceding sequence of non-whitespace ! 1131: characters is just a single token, so that the meaning will not change ! 1132: if we change the definition of this feature. 1.1.1.3 root 1133: 1134: 1.1.1.5 ! root 1135: File: gcc.info, Node: Subscripting, Next: Pointer Arith, Prev: Macro Varargs, Up: C Extensions ! 1136: ! 1137: Non-Lvalue Arrays May Have Subscripts ! 1138: ===================================== 1.1.1.3 root 1139: 1.1.1.5 ! root 1140: Subscripting is allowed on arrays that are not lvalues, even though ! 1141: the unary `&' operator is not. For example, this is valid in GNU C ! 1142: though not valid in other C dialects: 1.1.1.3 root 1143: 1.1.1.5 ! root 1144: struct foo {int a[4];}; ! 1145: ! 1146: struct foo f(); ! 1147: ! 1148: bar (int index) ! 1149: { ! 1150: return f().a[index]; ! 1151: } 1.1 root 1152: 1153: 1.1.1.5 ! root 1154: File: gcc.info, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: C Extensions 1.1.1.3 root 1155: 1.1.1.5 ! root 1156: Arithmetic on `void'- and Function-Pointers ! 1157: =========================================== 1.1.1.3 root 1158: 1.1.1.5 ! root 1159: In GNU C, addition and subtraction operations are supported on ! 1160: pointers to `void' and on pointers to functions. This is done by ! 1161: treating the size of a `void' or of a function as 1. 1.1.1.3 root 1162: 1.1.1.5 ! root 1163: A consequence of this is that `sizeof' is also allowed on `void' and ! 1164: on function types, and returns 1. 1.1.1.4 root 1165: 1.1.1.5 ! root 1166: The option `-Wpointer-arith' requests a warning if these extensions ! 1167: are used. 1.1.1.3 root 1168: 1169: 1.1.1.5 ! root 1170: File: gcc.info, Node: Initializers, Next: Constructors, Prev: Pointer Arith, Up: C Extensions 1.1 root 1171: 1.1.1.5 ! root 1172: Non-Constant Initializers ! 1173: ========================= ! 1174: ! 1175: The elements of an aggregate initializer for an automatic variable ! 1176: are not required to be constant expressions in GNU C. Here is an ! 1177: example of an initializer with run-time varying elements: ! 1178: ! 1179: foo (float f, float g) ! 1180: { ! 1181: float beat_freqs[2] = { f-g, f+g }; ! 1182: ... ! 1183: } ! 1184: ! 1185: ! 1186: File: gcc.info, Node: Constructors, Next: Labeled Elements, Prev: Initializers, Up: C Extensions ! 1187: ! 1188: Constructor Expressions 1.1.1.4 root 1189: ======================= 1190: 1.1.1.5 ! root 1191: GNU C supports constructor expressions. A constructor looks like a ! 1192: cast containing an initializer. Its value is an object of the type ! 1193: specified in the cast, containing the elements specified in the ! 1194: initializer. 1.1.1.4 root 1195: 1.1.1.5 ! root 1196: Usually, the specified type is a structure. Assume that `struct ! 1197: foo' and `structure' are declared as shown: 1.1.1.4 root 1198: 1.1.1.5 ! root 1199: struct foo {int a; char b[2];} structure; 1.1.1.4 root 1200: 1.1.1.5 ! root 1201: Here is an example of constructing a `struct foo' with a constructor: 1.1.1.4 root 1202: 1.1.1.5 ! root 1203: structure = ((struct foo) {x + y, 'a', 0}); 1.1.1.4 root 1204: 1.1.1.5 ! root 1205: This is equivalent to writing the following: 1.1 root 1206: 1.1.1.5 ! root 1207: { ! 1208: struct foo temp = {x + y, 'a', 0}; ! 1209: structure = temp; ! 1210: } ! 1211: ! 1212: You can also construct an array. If all the elements of the ! 1213: constructor are (made up of) simple constant expressions, suitable for ! 1214: use in initializers, then the constructor is an lvalue and can be ! 1215: coerced to a pointer to its first element, as shown here: ! 1216: ! 1217: char **foo = (char *[]) { "x", "y", "z" }; ! 1218: ! 1219: Array constructors whose elements are not simple constants are not ! 1220: very useful, because the constructor is not an lvalue. There are only ! 1221: two valid ways to use it: to subscript it, or initialize an array ! 1222: variable with it. The former is probably slower than a `switch' ! 1223: statement, while the latter does the same thing an ordinary C ! 1224: initializer would do. Here is an example of subscripting an array ! 1225: constructor: 1.1 root 1226: 1.1.1.5 ! root 1227: output = ((int[]) { 2, x, 28 }) [input]; ! 1228: ! 1229: Constructor expressions for scalar types and union types are is also ! 1230: allowed, but then the constructor expression is equivalent to a cast. 1.1 root 1231: 1232: 1.1.1.5 ! root 1233: File: gcc.info, Node: Labeled Elements, Next: Cast to Union, Prev: Constructors, Up: C Extensions 1.1 root 1234: 1.1.1.5 ! root 1235: Labeled Elements in Initializers 1.1.1.4 root 1236: ================================ 1.1 root 1237: 1.1.1.5 ! root 1238: Standard C requires the elements of an initializer to appear in a ! 1239: fixed order, the same as the order of the elements in the array or ! 1240: structure being initialized. 1.1 root 1241: 1.1.1.5 ! root 1242: In GNU C you can give the elements in any order, specifying the array ! 1243: indices or structure field names they apply to. 1.1 root 1244: 1.1.1.5 ! root 1245: To specify an array index, write `[INDEX]' before the element value. ! 1246: For example, 1.1 root 1247: 1.1.1.5 ! root 1248: int a[6] = { [4] 29, [2] 15 }; 1.1.1.4 root 1249: 1.1.1.5 ! root 1250: is equivalent to 1.1 root 1251: 1.1.1.5 ! root 1252: int a[6] = { 0, 0, 15, 0, 29, 0 }; 1.1 root 1253: 1.1.1.5 ! root 1254: The index values must be constant expressions, even if the array being ! 1255: initialized is automatic. ! 1256: ! 1257: In a structure initializer, specify the name of a field to initialize ! 1258: with `FIELDNAME:' before the element value. For example, given the ! 1259: following structure, ! 1260: ! 1261: struct point { int x, y; }; ! 1262: ! 1263: the following initialization ! 1264: ! 1265: struct point p = { y: yvalue, x: xvalue }; ! 1266: ! 1267: is equivalent to ! 1268: ! 1269: struct point p = { xvalue, yvalue }; ! 1270: ! 1271: You can also use an element label when initializing a union, to ! 1272: specify which element of the union should be used. For example, ! 1273: ! 1274: union foo { int i; double d; }; ! 1275: ! 1276: union foo f = { d: 4 }; ! 1277: ! 1278: will convert 4 to a `double' to store it in the union using the second ! 1279: element. By contrast, casting 4 to type `union foo' would store it ! 1280: into the union as the integer `i', since it is an integer. (*Note Cast ! 1281: to Union::.) ! 1282: ! 1283: You can combine this technique of naming elements with ordinary C ! 1284: initialization of successive elements. Each initializer element that ! 1285: does not have a label applies to the next consecutive element of the ! 1286: array or structure. For example, ! 1287: ! 1288: int a[6] = { [1] v1, v2, [4] v4 }; ! 1289: ! 1290: is equivalent to ! 1291: ! 1292: int a[6] = { 0, v1, v2, 0, v4, 0 }; ! 1293: ! 1294: Labeling the elements of an array initializer is especially useful ! 1295: when the indices are characters or belong to an `enum' type. For ! 1296: example: 1.1.1.4 root 1297: 1.1.1.5 ! root 1298: int whitespace[256] ! 1299: = { [' '] 1, ['\t'] 1, ['\h'] 1, ! 1300: ['\f'] 1, ['\n'] 1, ['\r'] 1 }; 1.1 root 1301:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.