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