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