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