Return to gcc.info-4 CVS log

Up to [GCC 2.x] / gcc

Annotation of gcc/gcc.info-4, revision 1.1

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

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.