![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-4 CVS log | Up to [GCC 2.x] / gcc |
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.