forked from debrouxl/gcc4ti
-
Notifications
You must be signed in to change notification settings - Fork 0
/
gnuexts.html
3432 lines (3293 loc) · 174 KB
/
gnuexts.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>GNU C Language Extensions</TITLE>
<STYLE TYPE="TEXT/CSS">
<!--
.IE3-DUMMY { CONT-SIZE: 100%; }
BODY { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; BACKGROUND-COLOR: #E0E0E0; }
P { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; }
H1 { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; }
H2 { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; }
H3 { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; }
H4 { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; }
H5 { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; }
H6 { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; }
UL { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; }
TD { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; BACKGROUND-COLOR: #FFFFFF; }
.NOBORDER { BACKGROUND-COLOR: #E0E0E0; PADDING: 0pt; }
.NOBORDER TD { FONT-FAMILY: Verdana,Arial,Helvetica,Sans-Serif; BACKGROUND-COLOR: #E0E0E0; PADDING: 0pt; }
.CODE { FONT-FAMILY: Courier New; }
-->
</STYLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#E0E0E0">
<FONT SIZE="5"><B>GNU C Language Extensions</B></FONT>
<HR>
<P>This part of the documentation is a modified version of the <A HREF="http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html">C Extensions</A> section of the <A HREF="http://gcc.gnu.org/onlinedocs/gcc/">GCC Manual</A>.
Therefore it is licensed under the <A HREF="gnugpl.html#gnufdl">GNU Free Documentation License</A>.
<BR><BR>
GCC4TI (like all GNU C compilers) provides several language features not found
in ISO standard C. To test for the availability of these
features in conditional compilation, check for a predefined macro
<CODE><A HREF="cpp.html#SEC15_GNUC">__GNUC__</A></CODE>, which is always defined under GCC.
<BR><BR>
Some features that are in ISO C99 but not C89 are also, as
extensions, accepted by GCC in C89 mode.</P>
<UL>
<LI><B><A HREF="#SEC63">Statements and Declarations in Expressions</A></B>
<LI><B><A HREF="#SEC64">Locally Declared Labels</A></B>
<LI><B><A HREF="#SEC65">Labels as Values</A></B>
<LI><B><A HREF="#SEC66">Nested Functions</A></B>
<LI><B><A HREF="#SEC67">Constructing Function Calls</A></B>
<LI><B><A HREF="#SEC69">Referring to a Type with 'typeof'</A></B>
<LI><B><A HREF="#SEC70">Generalized Lvalues</A></B>
<LI><B><A HREF="#SEC71">Conditionals with Omitted Operands</A></B>
<LI><B><A HREF="#SEC72">Double-Word Integers</A></B>
<LI><B><A HREF="#SEC73">Complex Numbers</A></B>
<LI><B><A HREF="#SEC74">Hex Floats</A></B>
<LI><B><A HREF="#SEC110">Binary Numbers</A></B>
<LI><B><A HREF="#SEC111">Structures With No Members</A></B>
<LI><B><A HREF="#SEC75">Arrays of Length Zero</A></B>
<LI><B><A HREF="#SEC76">Arrays of Variable Length</A></B>
<LI><B><A HREF="#SEC77">Macros with a Variable Number of Arguments</A></B>
<LI><B><A HREF="#SEC78">Non-Lvalue Arrays May Have Subscripts</A></B>
<LI><B><A HREF="#SEC79">Arithmetic on void and Function Pointers</A></B>
<LI><B><A HREF="#SEC80">Non-Constant Initializers</A></B>
<LI><B><A HREF="#SEC81">Compound Literals (Cast Constructors)</A></B>
<LI><B><A HREF="#SEC82">Designated Initializers</A></B>
<LI><B><A HREF="#SEC84">Cast to a Union Type</A></B>
<LI><B><A HREF="#SEC83">Case Ranges</A></B>
<LI><B><A HREF="#SEC85">Specifying Attributes of Functions</A></B>
<LI><B><A HREF="#SEC91">Specifying Attributes of Variables</A></B>
<LI><B><A HREF="#SEC92">Specifying Attributes of Types</A></B>
<LI><B><A HREF="#SEC85a">Attribute Syntax</A></B>
<LI><B><A HREF="#SEC86">Prototypes and Old-Style Function Definitions</A></B>
<LI><B><A HREF="#SEC87">C++ Style Comments</A></B>
<LI><B><A HREF="#SEC88">Dollar Signs in Identifier Names</A></B>
<LI><B><A HREF="#SEC89">Escape Character in Constants</A></B>
<LI><B><A HREF="#SEC90">Inquiring on Alignment of Types or Variables</A></B>
<LI><B><A HREF="#SEC93">Inline Functions</A></B>
<LI><B><A HREF="#SEC94_asm">Inline Assembler</A></B>
<LI><B><A HREF="#SEC96">Controlling Names Used in Assembler Code</A></B>
<LI><B><A HREF="#SEC97">Variables in Specified Registers</A></B>
<LI><B><A HREF="#SEC100">Alternate Keywords</A></B>
<LI><B><A HREF="#SEC101">Incomplete 'enum' Types</A></B>
<LI><B><A HREF="#SEC102">Function Names as Strings</A></B>
<LI><B><A HREF="#SEC103">Getting the Return or Frame Address of a Function</A></B>
<LI><B><A HREF="#SEC104">Other built-in functions provided by GCC</A></B>
<LI><B><A HREF="#SEC105">Slightly Looser Rules for Escaped Newlines</A></B>
<LI><B><A HREF="#SEC106">String Literals with Embedded Newlines</A></B>
<LI><B><A HREF="#SEC107">Mixed Declarations and Code</A></B>
<LI><B><A HREF="#SEC108">Unnamed struct/union Fields within structs/unions</A></B>
<LI><B><A HREF="#SEC109">Definite Access of Volatile Objects</A></B>
<LI><B><A HREF="#history">History</A></B>
<LI><B><A HREF="gnugpl.html">GNU General Public License</A></B>
<LI><B><A HREF="gnugpl.html#gnufdl">GNU Free Documentation License</A></B>
<LI><B><A HREF="gnugpl.html#funding">Funding Free Software</A></B>
</UL>
<P>Original author: Free Software Foundation, Inc.
<BR>
Authors of the modifications: Zeljko Juric, Sebastian Reichelt, and Kevin Kofler
<BR>
Published by the TIGCC Team, and now the GCC4TI project.
<BR>
See the <A HREF="#history">History</A> section for details and copyright information.
<BR><BR>
Permission is granted to copy, distribute and/or modify this document
under the terms of the <A HREF="gnugpl.html#gnufdl">GNU Free Documentation License</A>, Version 1.1 or any
later version published by the Free Software Foundation; with the Invariant
Sections being "<A HREF="gnugpl.html">GNU General Public License</A>" and "<A HREF="gnugpl.html#funding">Funding Free Software</A>", the
Front-Cover texts being (a) (see below), and with the Back-Cover Texts being
(b) (see below). A copy of the license is included in the section entitled
"<A HREF="gnugpl.html#gnufdl">GNU Free Documentation License</A>".
<BR><BR>
(a) The FSF's Front-Cover Text is:
<BR><BR>
A GNU Manual
<BR><BR>
(b) The FSF's Back-Cover Text is:
<BR><BR>
You have freedom to copy and modify this GNU Manual, like GNU software.
Copies published by the Free Software Foundation raise funds for GNU
development.</P>
<HR>
<H2><A NAME="SEC63"><U>Statements and Declarations in Expressions</U></A></H2>
<P>A compound statement enclosed in parentheses may appear as an expression
in GNU C. This allows you to use loops, switches, and local variables
within an expression.
<BR><BR>
Recall that a compound statement is a sequence of statements surrounded
by braces; in this construct, parentheses go around the braces. For
example:</P>
<PRE>({ int y = foo (); int z;
if (y > 0) z = y;
else z = - y;
z; })
</PRE>
<P>is a valid (though slightly more complex than necessary) expression
for the absolute value of <CODE>foo ()</CODE>.
<BR><BR>
The last thing in the compound statement should be an expression
followed by a semicolon; the value of this subexpression serves as the
value of the entire construct. (If you use some other kind of statement
last within the braces, the construct has type <CODE><A HREF="keywords.html#void">void</A></CODE>, and thus
effectively no value.)
<BR><BR>
This feature is especially useful in making macro definitions "safe" (so
that they evaluate each operand exactly once). For example, the
"maximum" function is commonly defined as a macro in standard C as
follows:</P>
<PRE>#define max(a,b) ((a) > (b) ? (a) : (b))
</PRE>
<P>But this definition computes either <I>a</I> or <I>b</I> twice, with bad
results if the operand has side effects. In GNU C, if you know the
type of the operands (here let's assume <CODE><A HREF="keywords.html#int">int</A></CODE>), you can define
the macro safely as follows:</P>
<PRE>#define maxint(a,b) \
({int _a = (a), _b = (b); _a > _b ? _a : _b; })
</PRE>
<P>Embedded statements are not allowed in constant expressions, such as
the value of an enumeration constant, the width of a bit-field, or
the initial value of a static variable.
<BR><BR>
If you don't know the type of the operand, you can still do this, but you
must use <CODE><A HREF="#SEC69">typeof</A></CODE>.</P>
<HR>
<H2><A NAME="SEC64"><U>Locally Declared Labels</U></A></H2>
<P>Each statement expression is a scope in which <U>local labels</U> can be
declared. A local label is simply an identifier; you can jump to it
with an ordinary <CODE><A HREF="keywords.html#goto">goto</A></CODE> statement, but only from within the
statement expression it belongs to.
<BR><BR>
A local label declaration looks like this:</P>
<PRE>__label__ <I>label</I>;
</PRE>
<P>or</P>
<PRE>__label__ <I>label1</I>, <I>label2</I>, /* ... */;
</PRE>
<P>Local label declarations must come at the beginning of the statement
expression, right after the <CODE>({</CODE>, before any ordinary
declarations.
<BR><BR>
The label declaration defines the label <I>name</I>, but does not define
the label itself. You must do this in the usual way, with
<CODE><I>label</I>:</CODE>, within the statements of the statement expression.
<BR><BR>
The local label feature is useful because statement expressions are
often used in macros. If the macro contains nested loops, a <CODE><A HREF="keywords.html#goto">goto</A></CODE>
can be useful for breaking out of them. However, an ordinary label
whose scope is the whole function cannot be used: if the macro can be
expanded several times in one function, the label will be multiply
defined in that function. A local label avoids this problem. For
example:</P>
<PRE>#define SEARCH(array, target) \
({ \
__label__ found; \
typeof (target) _SEARCH_target = (target); \
typeof (*(array)) *_SEARCH_array = (array); \
int i, j; \
int value; \
for (i = 0; i < max; i++) \
for (j = 0; j < max; j++) \
if (_SEARCH_array[i][j] == _SEARCH_target) \
{ value = i; goto found; } \
value = -1; \
found: \
value; \
})
</PRE>
<HR>
<H2><A NAME="SEC65"><U>Labels as Values</U></A></H2>
<P>You can get the address of a label defined in the current function
(or a containing function) with the unary operator <CODE>&&</CODE>. The
+ value has type <CODE><A HREF="keywords.html#void">void</A>*</CODE>. This value is a constant and can be used
wherever a constant of that type is valid. For example:</P>
<PRE>void *ptr;
/* ... */
ptr = &&foo;
</PRE>
<P>To use these values, you need to be able to jump to one. This is done
with the computed goto statement, <CODE><A HREF="keywords.html#goto">goto</A> *<I>exp</I>;</CODE>. For example,</P>
<PRE>goto *ptr;
</PRE>
<P>Any expression of type <CODE><A HREF="keywords.html#void">void</A>*</CODE> is allowed.
<BR><BR>
One way of using these constants is in initializing a static array that
will serve as a jump table:</P>
<PRE>static void *array[] = { &&foo, &&bar, &&hack };
</PRE>
<P>Then you can select a label with indexing, like this:</P>
<PRE>goto *array[i];
</PRE>
<P>Note that this does not check whether the subscript is in bounds - array
indexing in C never does that.
<BR><BR>
Such an array of label values serves a purpose much like that of the
<CODE><A HREF="keywords.html#switch">switch</A></CODE> statement. The <CODE>switch</CODE> statement is cleaner, so
use that rather than an array unless the problem does not fit a
<CODE>switch</CODE> statement very well.
<BR><BR>
You may not use this mechanism to jump to code in a different function.
If you do that, totally unpredictable things will happen. The best way to
avoid this is to store the label address only in automatic variables and
never pass it as an argument.
<BR><BR>
An alternate way to write the above example is</P>
<PRE>static const int array[] = { &&foo - &&foo, &&bar - &&foo,
&&hack - &&foo };
goto *(&&foo + array[i]);
</PRE>
<P>This is more friendly to code living in shared libraries (DLLs), as it reduces
the number of dynamic relocations that are needed (and, by consequence,
would allow the data to be read-only).</P>
<HR>
<H2><A NAME="SEC66"><U>Nested Functions</U></A></H2>
<P>A <U>nested function</U> is a function defined inside another function.
The nested function's
name is local to the block where it is defined. For example, here we
define a nested function named <CODE>square</CODE>, and call it twice:</P>
<PRE>double square_sum (double a, double b)
{
double square (double z)
{
return z * z;
}
return square (a) + square (b);
}
</PRE>
<P>The nested function can access all the variables of the containing
function that are visible at the point of its definition. This is
called <U>lexical scoping</U>. For example, here we show a nested
function which uses an inherited variable named <CODE>offset</CODE>:</P>
<PRE>int foo (int *array, int offset, int size)
{
int access (int *array, int index)
{
return array[index + offset];
}
int i;
/* ... */
for (i = 0; i < size; i++)
/* ... */ access (array, i) /* ... */
}
</PRE>
<P>Nested function definitions are permitted within functions in the places
where variable definitions are allowed; that is, in any block, before
the first statement in the block.
<BR><BR>
It is possible to call the nested function from outside the scope of its
name by storing its address or passing the address to another function:</P>
<PRE>int hack (int *array, int size)
{
void store (int index, int value)
{
array[index] = value;
}
intermediate (store, size);
}
</PRE>
<P>Here, the function <CODE>intermediate</CODE> receives the address of
<CODE>store</CODE> as an argument. If <CODE>intermediate</CODE> calls <CODE>store</CODE>,
the arguments given to <CODE>store</CODE> are used to store into <CODE>array</CODE>.
But this technique works only so long as the containing function
(<CODE>hack</CODE>, in this example) does not exit.
<BR><BR>
If you try to call the nested function through its address after the
containing function has exited, all hell will break loose. If you try
to call it after a containing scope level has exited, and if it refers
to some of the variables that are no longer in scope, you may be lucky,
but it's not wise to take the risk. If, however, the nested function
does not refer to anything that has gone out of scope, you should be
safe.
<BR><BR>
GCC implements taking the address of a nested function using a technique
called <U>trampolines</U>. A paper describing them is available at
<A HREF="http://people.debian.org/~aaronl/Usenix88-lexic.pdf">http://people.debian.org/~aaronl/Usenix88-lexic.pdf</A>.
Note that trampolines are currently broken in GCC4TI; they create code on the
stack, which can make HW2 calculators crash.
<BR><BR>
A nested function can jump to a label inherited from a containing
function, provided the label was explicitly declared in the containing
function (see <A HREF="#SEC64">Local Labels</A>). Such a jump returns instantly to the
containing function, exiting the nested function which did the
<CODE><A HREF="keywords.html#goto">goto</A></CODE> and any intermediate functions as well. Here is an example:</P>
<PRE>int bar (int *array, int offset, int size)
{
__label__ failure;
int access (int *array, int index)
{
if (index > size)
goto failure;
return array[index + offset];
}
int i;
/* ... */
for (i = 0; i < size; i++)
/* ... */ access (array, i) /* ... */
/* ... */
return 0;
/* Control comes here from 'access'
if it detects an error. */
failure:
return -1;
}
</PRE>
<P>A nested function always has internal linkage. Declaring one with
<CODE>extern</CODE> is erroneous. If you need to declare the nested function
before its definition, use <CODE><A HREF="keywords.html#auto">auto</A></CODE> (which is otherwise meaningless
for function declarations).</P>
<PRE>int bar (int *array, int offset, int size)
{
__label__ failure;
auto int access (int *, int);
/* ... */
int access (int *array, int index)
{
if (index > size)
goto failure;
return array[index + offset];
}
/* ... */
}
</PRE>
<HR>
<H2><A NAME="SEC67"><U>Constructing Function Calls</U></A></H2>
<P>Using the built-in functions described below, you can record
the arguments a function received, and call another function
with the same arguments, without knowing the number or types
of the arguments.
<BR><BR>
You can also record the return value of that function call,
and later return that value, without knowing what data type
the function tried to return (as long as your caller expects
that data type).</P>
<UL>
<LI><B><A HREF="#SEC67___builtin_apply_args">__builtin_apply_args</A></B>
<LI><B><A HREF="#SEC67___builtin_apply">__builtin_apply</A></B>
<LI><B><A HREF="#SEC67___builtin_return">__builtin_return</A></B>
</UL>
<H3><A NAME="SEC67___builtin_apply_args"><U>__builtin_apply_args</U></A></H3>
<P><CODE><B><A HREF="keywords.html#void">void</A></B> *__builtin_apply_args (<B><A HREF="keywords.html#void">void</A></B>);</CODE>
<BR><BR>
This built-in function returns a pointer to data
describing how to perform a call with the same arguments as were passed
to the current function.
<BR><BR>
The function saves the arg pointer register, structure value address,
and all registers that might be used to pass arguments to a function
into a block of memory allocated on the stack. Then it returns the
address of that block.</P>
<H3><A NAME="SEC67___builtin_apply"><U>__builtin_apply</U></A></H3>
<P><CODE><B><A HREF="keywords.html#void">void</A></B> *__builtin_apply (<B><A HREF="keywords.html#void">void</A></B> (*fnc)(), <B><A HREF="keywords.html#void">void</A></B> *args, <B><A HREF="keywords.html#int">int</A></B> size);</CODE>
<BR><BR>
This built-in function invokes <I>function</I>
with a copy of the parameters described by <I>arguments</I>
and <I>size</I>.
<BR><BR>
The value of <I>arguments</I> should be the value returned by
<A HREF="#SEC67___builtin_apply_args">__builtin_apply_args</A>.
The argument <I>size</I> specifies the size
of the stack argument data, in bytes.
<BR><BR>
This function returns a pointer to data describing
how to return whatever value was returned by <I>function</I>. The data
is saved in a block of memory allocated on the stack.
<BR><BR>
It is not always simple to compute the proper value for <I>size</I>. The
value is used by __builtin_apply to compute the amount of data
that should be pushed on the stack and copied from the incoming argument
area.</P>
<H3><A NAME="SEC67___builtin_return"><U>__builtin_return</U></A></H3>
<P><CODE><B><A HREF="keywords.html#void">void</A></B> __builtin_return (<B><A HREF="keywords.html#void">void</A></B> *result);</CODE>
<BR><BR>
This built-in function returns the value described by <I>result</I> from
the containing function. You should specify, for <I>result</I>, a value
returned by <A HREF="#SEC67___builtin_apply">__builtin_apply</A>.</P>
<HR>
<H2><A NAME="SEC69"><U>Referring to a Type with 'typeof'</U></A></H2>
<P>Another way to refer to the type of an expression is with <CODE>typeof</CODE>.
The syntax of using of this keyword looks like <CODE><A HREF="keywords.html#sizeof">sizeof</A></CODE>, but the
construct acts semantically like a type name defined with <CODE><A HREF="keywords.html#typedef">typedef</A></CODE>.
<BR><BR>
There are two ways of writing the argument to <CODE>typeof</CODE>: with an
expression or with a type. Here is an example with an expression:</P>
<PRE>typeof (x[0](1))
</PRE>
<P>This assumes that <I>x</I> is an array of pointers to functions;
the type described is that of the values of the functions.
<BR><BR>
Here is an example with a typename as the argument:</P>
<PRE>typeof (int *)
</PRE>
<P>Here the type described is that of pointers to <CODE><A HREF="keywords.html#int">int</A></CODE>.
<BR><BR>
An alternate keyword for <CODE>typeof</CODE> is <CODE>__typeof__</CODE>.
See <A HREF="#SEC100">Alternate Keywords</A>.
<BR><BR>
A <CODE>typeof</CODE>-construct can be used anywhere a typedef name could be
used. For example, you can use it in a declaration, in a cast, or inside
of <CODE><A HREF="keywords.html#sizeof">sizeof</A></CODE> or <CODE>typeof</CODE>.
<BR><BR>
<CODE>typeof</CODE> is often useful in conjunction with the
statements-within-expressions feature. Here is how the two together can
be used to define a safe "maximum" macro that operates on any
arithmetic type and evaluates each of its arguments exactly once:</P>
<PRE>#define max(a,b) \
({ typeof (a) _a = (a); \
typeof (b) _b = (b); \
_a > _b ? _a : _b; })
</PRE>
<P>The reason for using names that start with underscores for the local
variables is to avoid conflicts with variable names that occur within the
expressions that are substituted for <CODE>a</CODE> and <CODE>b</CODE>. Eventually we
hope to design a new form of declaration syntax that allows you to declare
variables whose scopes start only after their initializers; this will be a
more reliable way to prevent such conflicts.
<BR><BR>
Some more examples of the use of <CODE>typeof</CODE>:</P>
<UL>
<LI><P>This declares <I>y</I> with the type of what <I>x</I> points to.</P>
<PRE>typeof (*x) y;
</PRE>
</LI>
<LI><P>This declares <I>y</I> as an array of such values.</P>
<PRE>typeof (*x) y[4];
</PRE>
</LI>
<LI><P>This declares <I>y</I> as an array of pointers to characters:</P>
<PRE>typeof (typeof (char *)[4]) y;
</PRE>
<P>It is equivalent to the following traditional C declaration:</P>
<PRE>char *y[4];
</PRE>
<P>To see the meaning of the declaration using <CODE>typeof</CODE>, and why it
might be a useful way to write, let's rewrite it with these macros:</P>
<PRE>#define pointer(T) typeof(T *)
#define array(T, N) typeof(T [N])
</PRE>
<P>Now the declaration can be rewritten this way:</P>
<PRE>array (pointer (char), 4) y;
</PRE>
<P>Thus, <CODE>array (pointer (char), 4)</CODE> is the type of arrays of 4
pointers to <CODE>char</CODE>.</P></LI>
</UL>
<P><I>Compatibility Note:</I> In addition to <CODE>typeof</CODE>, GCC 2 supported
a more limited extension which permitted one to write</P>
<PRE>typedef <I>T</I> = <I>expr</I>;
</PRE>
<P>with the effect of declaring <I>T</I> to have the type of the expression
<I>expr</I>. This extension does not work with GCC 3 (versions between
3.0 and 3.2 will crash; 3.2.1 and later give an error). Code which
relies on it should be rewritten to use <CODE>typeof</CODE>:</P>
<PRE>typedef typeof(<I>expr</I>) <I>T</I>;
</PRE>
<P>This will work with all versions of GCC.</P>
<HR>
<H2><A NAME="SEC70"><U>Generalized Lvalues</U></A></H2>
<P>Compound expressions, conditional expressions and casts are allowed as
lvalues provided their operands are lvalues. This means that you can take
their addresses or store values into them.
<BR><BR>
For example, a compound expression can be assigned, provided the last
expression in the sequence is an lvalue. These two expressions are
equivalent:</P>
<PRE>(a, b) += 5
a, (b += 5)
</PRE>
<P>Similarly, the address of the compound expression can be taken. These two
expressions are equivalent:</P>
<PRE>&(a, b)
a, &b
</PRE>
<P>A conditional expression is a valid lvalue if its type is not void and the
true and false branches are both valid lvalues. For example, these two
expressions are equivalent:</P>
<PRE>(a ? b : c) = 5
(a ? b = 5 : (c = 5))
</PRE>
<P>A cast is a valid lvalue if its operand is an lvalue. A simple
assignment whose left-hand side is a cast works by converting the
right-hand side first to the specified type, then to the type of the
inner left-hand side expression. After this is stored, the value is
converted back to the specified type to become the value of the
assignment. Thus, if <CODE>a</CODE> has type <CODE><A HREF="keywords.html#int">char</A>*</CODE>, the following two
expressions are equivalent:</P>
<PRE>(int)a = 5
(int)(a = (char *)(int)5)
</PRE>
<P>An assignment-with-arithmetic operation such as <CODE>+=</CODE> applied to a cast
performs the arithmetic using the type resulting from the cast, and then
continues as in the previous case. Therefore, these two expressions are
equivalent:</P>
<PRE>(int)a += 5
(int)(a = (char *)(int) ((int)a + 5))
</PRE>
<P>You cannot take the address of an lvalue cast, because the use of its
address would not work out coherently. Suppose that <CODE>&(int)f</CODE> were
permitted, where <CODE>f</CODE> has type <CODE><A HREF="keywords.html#float">float</A></CODE>. Then the following
statement would try to store an integer bit-pattern where a floating
point number belongs:</P>
<PRE>*&(int)f = 1;
</PRE>
<P>This is quite different from what <CODE>(int)f = 1</CODE> would do - that
would convert 1 to floating point and store it. Rather than cause this
inconsistency, the GNU team thinks it is better to prohibit use of <CODE>&</CODE> on a cast.
<BR><BR>
If you really do want an <CODE><A HREF="keywords.html#int">int</A>*</CODE> pointer with the address of
<CODE>f</CODE>, you can simply write <CODE>(int*)&f</CODE>.</P>
<HR>
<H2><A NAME="SEC71"><U>Conditionals with Omitted Operands</U></A></H2>
<P>The middle operand in a conditional expression may be omitted. Then
if the first operand is nonzero, its value is the value of the conditional
expression.
<BR><BR>
Therefore, the expression</P>
<PRE>x ? : y
</PRE>
<P>has the value of <CODE>x</CODE> if that is nonzero; otherwise, the value of
<CODE>y</CODE>.
<BR><BR>
This example is perfectly equivalent to</P>
<PRE>x ? x : y
</PRE>
<P>In this simple case, the ability to omit the middle operand is not
especially useful. When it becomes useful is when the first operand does,
or may (if it is a macro argument), contain a side effect. Then repeating
the operand in the middle would perform the side effect twice. Omitting
the middle operand uses the value already computed without the undesirable
effects of recomputing it.</P>
<HR>
<H2><A NAME="SEC72"><U>Double-Word Integers</U></A></H2>
<P>ISO C99 supports data types for integers that are at least 64 bits wide,
and as an extension GCC supports them in C89 mode.
Simply write <CODE><A HREF="keywords.html#short">long</A> <A HREF="keywords.html#short">long</A> <A HREF="keywords.html#int">int</A></CODE> for a signed integer, or
<CODE><A HREF="keywords.html#short">unsigned</A> <A HREF="keywords.html#short">long</A> <A HREF="keywords.html#short">long</A> <A HREF="keywords.html#int">int</A></CODE> for an unsigned integer. To make an
integer constant of type <CODE>long long int</CODE>, add the suffix <CODE>LL</CODE>
to the integer. To make an integer constant of type <CODE>unsigned long
long int</CODE>, add the suffix <CODE>ULL</CODE> to the integer.
<BR><BR>
You can use these types in arithmetic like any other integer types.
Addition, subtraction, and bitwise boolean operations on these types
are open-coded on all types of machines, as well as shifts with a constant
value. Multiplication, division and shifts are not open-coded and use
special library routines.
<BR><BR>
There may be pitfalls when you use <CODE>long long</CODE> types for function
arguments, unless you declare function prototypes. If a function
expects type <CODE><A HREF="keywords.html#int">int</A></CODE> for its argument, and you pass a value of type
<CODE><A HREF="keywords.html#short">long</A> <A HREF="keywords.html#short">long</A> <A HREF="keywords.html#int">int</A></CODE>, confusion will result because the caller and the
subroutine will disagree about the number of bytes for the argument.
Likewise, if the function expects <CODE><A HREF="keywords.html#short">long</A> <A HREF="keywords.html#short">long</A> <A HREF="keywords.html#int">int</A></CODE> and you pass
<CODE><A HREF="keywords.html#int">int</A></CODE>. The best way to avoid such problems is to use prototypes.</P>
<HR>
<H2><A NAME="SEC73"><U>Complex Numbers</U></A></H2>
<P>ISO C99 supports complex floating data types, and as an extension GCC
supports them in C89 mode, and supports complex integer data
types which are not part of ISO C99. You can declare complex types
using the keyword <CODE>_Complex</CODE>. As an extension, the older GNU
keyword <CODE>__complex__</CODE> is also supported.
<BR><BR>
For example, <CODE>_Complex double x;</CODE> declares <CODE>x</CODE> as a
variable whose real part and imaginary part are both of type
<CODE><A HREF="keywords.html#float">double</A></CODE>. <CODE>_Complex short int y;</CODE> declares <CODE>y</CODE> to
have real and imaginary parts of type <CODE><A HREF="keywords.html#short">short</A> <A HREF="keywords.html#int">int</A></CODE>; this is not
likely to be useful, but it shows that the set of complex types is
complete.
<BR><BR>
To write a constant with a complex data type, use the suffix <CODE>i</CODE> or
<CODE>j</CODE> (either one; they are equivalent). For example, <CODE>2.5fi</CODE>
has type <CODE>_Complex float</CODE> and <CODE>3i</CODE> has type
<CODE>_Complex int</CODE>. Such a constant always has a pure imaginary
value, but you can form any complex value you like by adding one to a
real constant. This is a GNU extension; once GCC4TI supports this, you should include <CODE><complex.h></CODE> and
use the macros <CODE>I</CODE> or <CODE>_Complex_I</CODE> instead.
<BR><BR>
To extract the real part of a complex-valued expression <I>exp</I>, write
<CODE>__real__ <I>exp</I></CODE>. Likewise, use <CODE>__imag__</CODE> to
extract the imaginary part. This is a GNU extension; for values of
floating type, you should use the ISO C99 functions <CODE>crealf</CODE>,
<CODE>creal</CODE>, <CODE>creall</CODE>, <CODE>cimagf</CODE>, <CODE>cimag</CODE> and
<CODE>cimagl</CODE>, declared in <CODE><complex.h></CODE> (not yet available in GCC4TI) and also provided as
built-in functions by GCC.
<BR><BR>
The operator <CODE>~</CODE> performs complex conjugation when used on a value
with a complex type. This is a GNU extension; for values of
floating type, you should use the ISO C99 functions <CODE>conjf</CODE>,
<CODE>conj</CODE> and <CODE>conjl</CODE>, declared in <CODE><complex.h></CODE> and also
provided as built-in functions by GCC.
<BR><BR>
GCC can allocate complex automatic variables in a noncontiguous
fashion; it's even possible for the real part to be in a register while
the imaginary part is on the stack (or vice-versa).</P>
<HR>
<H2><A NAME="SEC74"><U>Hex Floats</U></A></H2>
<P>ISO C99 supports floating-point numbers written not only in the usual
decimal notation, such as <CODE>1.55e1</CODE>, but also numbers such as
<CODE>0x1.fp3</CODE> written in hexadecimal format. As a GNU extension, GCC
supports this in C89 mode (except in some cases when strictly
conforming). In that format the
<CODE>0x</CODE> hex introducer and the <CODE>p</CODE> or <CODE>P</CODE> exponent field are
mandatory. The exponent is a decimal number that indicates the power of
2 by which the significant part will be multiplied. Thus <CODE>0x1.f</CODE> is
<CODE>1 15/16</CODE>,
<CODE>p3</CODE> multiplies it by 8, and the value of <CODE>0x1.fp3</CODE>
is the same as <CODE>1.55e1</CODE>.
<BR><BR>
Unlike for floating-point numbers in the decimal notation the exponent
is always required in the hexadecimal notation. Otherwise the compiler
would not be able to resolve the ambiguity of, e.g., <CODE>0x1.f</CODE>. This
could mean <CODE>1.0f</CODE> or <CODE>1.9375</CODE> since <CODE>f</CODE> is also the
extension for floating-point constants of type <CODE><A HREF="keywords.html#float">float</A></CODE>.</P>
<HR>
<H2><A NAME="SEC110"><U>Binary Numbers</U></A></H2>
<P>GCC4TI allows you to specify binary numbers by using a <CODE>0b</CODE> prefix. This can be handy
in many occasions, such as when trying to declare sprites in a way which actually allows you to see
the picture. For example, the following declaration defines a simple black and white 8x8 diagonal
cross:</P>
<PRE>unsigned char cross[8] =
{0b10000001,
0b01000010,
0b00100100,
0b00011000,
0b00011000,
0b00100100,
0b01000010,
0b10000001};
</PRE>
<HR>
<H2><A NAME="SEC111"><U>Structures With No Members</U></A></H2>
<P>GCC permits a C structure to have no members:</P>
<PRE>struct empty {
};
</PRE>
<P>The structure will have size zero. In C++, empty structures are part
of the language, and the language standard says they have size 1.</P>
<HR>
<H2><A NAME="SEC75"><U>Arrays of Length Zero</U></A></H2>
<P>Zero-length arrays are allowed in GNU C. They are very useful as the
last element of a structure which is really a header for a variable-length
object:</P>
<PRE>struct line {
int length;
char contents[0];
};
struct line *thisline = (struct line *)
malloc (sizeof (struct line) + this_length);
thisline->length = this_length;
</PRE>
<P>In ISO C90, you would have to give <I>contents</I> a length of 1, which
means either you waste space or complicate the argument to <A HREF="alloc.html#malloc">malloc</A>.
<BR><BR>
In ISO C99, you would use a <U>flexible array member</U>, which is
slightly different in syntax and semantics:</P>
<UL>
<LI><P>Flexible array members are written as <CODE>contents[]</CODE> without
the <CODE>0</CODE>.
</P></LI>
<LI><P>Flexible array members have incomplete type, and so the <CODE><A HREF="keywords.html#sizeof">sizeof</A></CODE>
operator may not be applied. As a quirk of the original implementation
of zero-length arrays, <CODE><A HREF="keywords.html#sizeof">sizeof</A></CODE> evaluates to zero.
</P></LI>
<LI><P>Flexible array members may only appear as the last member of a
<CODE><A HREF="keywords.html#struct">struct</A></CODE> that is otherwise non-empty.
</P></LI>
<LI><P>A structure containing a flexible array member, or a union containing
such a structure (possibly recursively), may not be a member of a
structure or an element of an array. (However, these uses are
permitted by GCC as extensions.)</P></LI>
</UL>
<P>GCC versions before 3.0 allowed zero-length arrays to be statically
initialized, as if they were flexible arrays. In addition to those
cases that were useful, it also allowed initializations in situations
that would corrupt later data. Non-empty initialization of zero-length
arrays is now treated like any case where there are more initializer
elements than the array holds, in that a suitable warning about "excess
elements in array" is given, and the excess elements (all of them, in
this case) are ignored.
<BR><BR>
Instead GCC allows static initialization of flexible array members.
This is equivalent to defining a new structure containing the original
structure followed by an array of sufficient size to contain the data.
I.e. in the following, <I>f1</I> is constructed as if it were declared
like <I>f2</I>.</P>
<PRE>struct f1 {
int x; int y[];
} f1 = { 1, { 2, 3, 4 } };
struct f2 {
struct f1 f1; int data[3];
} f2 = { { 1 }, { 2, 3, 4 } };
</PRE>
<P>The convenience of this extension is that <I>f1</I> has the desired
type, eliminating the need to consistently refer to <I>f2</I>.<I>f1</I>.
<BR><BR>
This has symmetry with normal static arrays, in that an array of
unknown size is also written with <CODE>[]</CODE>.
<BR><BR>
Of course, this extension only makes sense if the extra data comes at
the end of a top-level object, as otherwise we would be overwriting
data at subsequent offsets. To avoid undue complication and confusion
with initialization of deeply nested arrays, we simply disallow any
non-empty initialization except when the structure is the top-level
object. For example:</P>
<PRE>struct foo { int x; int y[]; };
struct bar { struct foo z; };
struct foo a = { 1, { 2, 3, 4 } }; // Valid.
struct bar b = { { 1, { 2, 3, 4 } } }; // Invalid.
struct bar c = { { 1, { } } }; // Valid.
struct foo d[1] = { { 1, { 2, 3, 4 } } }; // Invalid.
</PRE>
<HR>
<H2><A NAME="SEC76"><U>Arrays of Variable Length</U></A></H2>
<P>Variable-length automatic arrays are allowed in ISO C99, and as an
extension GCC accepts them in C89 mode. (However, GCC's
implementation of variable-length arrays does not yet conform in detail
to the ISO C99 standard.) These arrays are
declared like any other automatic arrays, but with a length that is not
a constant expression. The storage is allocated at the point of
declaration and deallocated when the brace-level is exited. For
example:</P>
<PRE>FILE *concat_fopen (const char *s1, const char *s2, const char *mode)
{
char str[strlen (s1) + strlen (s2) + 1];
strcpy (str, s1);
strcat (str, s2);
return fopen (str, mode);
}
</PRE>
<P>Jumping or breaking out of the scope of the array name deallocates the
storage. Jumping into the scope is not allowed; you get an error
message for it.
<BR><BR>
You can use the function <A HREF="alloc.html#alloca">alloca</A> to get an effect much like
variable-length arrays. The function <A HREF="alloc.html#alloca">alloca</A> is available in
many other C implementations (but not in all). On the other hand,
variable-length arrays are more elegant.
<BR><BR>
There are other differences between these two methods. Space allocated
with <A HREF="alloc.html#alloca">alloca</A> exists until the containing <I>function</I> returns.
The space for a variable-length array is deallocated as soon as the array
name's scope ends. (If you use both variable-length arrays and
<A HREF="alloc.html#alloca">alloca</A> in the same function, deallocation of a variable-length array
will also deallocate anything more recently allocated with <A HREF="alloc.html#alloca">alloca</A>.)
<BR><BR>
You can also use variable-length arrays as arguments to functions:</P>
<PRE>struct entry
tester (int len, char data[len][len])
{
/* ... */
}
</PRE>
<P>The length of an array is computed once when the storage is allocated
and is remembered for the scope of the array in case you access it with
<CODE><A HREF="keywords.html#sizeof">sizeof</A></CODE>.
<BR><BR>
If you want to pass the array first and the length afterward, you can
use a forward declaration in the parameter list - another GNU extension.</P>
<PRE>struct entry
tester (int len; char data[len][len], int len)
{
/* ... */
}
</PRE>
<P>The <CODE>int len</CODE> before the semicolon is a <U>parameter forward
declaration</U>, and it serves the purpose of making the name <I>len</I>
known when the declaration of <I>data</I> is parsed.
<BR><BR>
You can write any number of such parameter forward declarations in the
parameter list. They can be separated by commas or semicolons, but the
last one must end with a semicolon, which is followed by the "real"
parameter declarations. Each forward declaration must match a "real"
declaration in parameter name and data type. ISO C99 does not support
parameter forward declarations.</P>
<HR>
<H2><A NAME="SEC77"><U>Macros with a Variable Number of Arguments</U></A></H2>
<P>In the ISO C standard of 1999, a macro can be declared to accept a
variable number of arguments much as a function can. The syntax for
defining the macro is similar to that of a function. Here is an
example:</P>
<PRE>#define lprintf(format, ...) fprintf (log, format, __VA_ARGS__)
</PRE>
<P>Here <CODE>...</CODE> is a <U>variable argument</U>. In the invocation of
such a macro, it represents the zero or more tokens until the closing
parenthesis that ends the invocation, including any commas. This set of
tokens replaces the identifier <CODE>__VA_ARGS__</CODE> in the macro body
wherever it appears.
For more information, see <A HREF="cpp.html#SEC13">Variadic Macros</A>.
<BR><BR>
GCC has long supported variadic macros, and used a different syntax that
allowed you to give a name to the variable arguments just like any other
argument. Here is an example:</P>
<PRE>#define lprintf(format, args...) fprintf (stderr, format, args)
</PRE>
<P>This is in all ways equivalent to the ISO C example above, but arguably
more readable and descriptive.
<BR><BR>
GNU CPP has two further variadic macro extensions, and permits them to
be used with either of the above forms of macro definition.
<BR><BR>
In standard C, you are not allowed to leave the variable argument out
entirely; but you are allowed to pass an empty argument. For example,
this invocation is invalid in ISO C, because there is no comma after
the string:</P>
<PRE>lprintf ("A message");
</PRE>
<P>GNU CPP permits you to completely omit the variable arguments in this
way. In the above examples, the compiler would complain, though since
the expansion of the macro still has the extra comma after the format
string.
<BR><BR>
To help solve this problem, CPP behaves specially for variable arguments
used with the token paste operator, <CODE>##</CODE>. If instead you write</P>
<PRE>#define lprintf(format, ...) fprintf (log, format, ## __VA_ARGS__)
</PRE>
<P>and if the variable arguments are omitted or empty, the <CODE>##</CODE>
operator causes the preprocessor to remove the comma before it. If you
do provide some variable arguments in your macro invocation, GNU CPP
does not complain about the paste operation and instead places the
variable arguments after the comma. Just like any other pasted macro
argument, these arguments are not macro expanded.</P>
<HR>
<H2><A NAME="SEC78"><U>Non-Lvalue Arrays May Have Subscripts</U></A></H2>
<P>In ISO C99, arrays that are not lvalues still decay to pointers, and
may be subscripted, although they may not be modified or used after
the next sequence point and the unary <CODE>&</CODE> operator may not be
applied to them. As an extension, GCC allows such arrays to be
subscripted in C89 mode, though otherwise they do not decay to
pointers outside C99 mode. For example,
this is valid in GNU C though not valid in C89:</P>
<PRE>struct foo {int a[4];};
struct foo f();
bar (int index)
{
return f().a[index];
}
</PRE>
<HR>
<H2><A NAME="SEC79"><U>Arithmetic on void and Function Pointers</U></A></H2>
<P>In GNU C, addition and subtraction operations are supported on pointers to
<CODE><A HREF="keywords.html#void">void</A></CODE> and on pointers to functions. This is done by treating the
size of a <CODE><A HREF="keywords.html#void">void</A></CODE> or of a function as 1.
<BR><BR>
A consequence of this is that <CODE><A HREF="keywords.html#sizeof">sizeof</A></CODE> is also allowed on <CODE><A HREF="keywords.html#void">void</A></CODE>
and on function types, and returns 1.
<BR><BR>
The option <B>'-Wpointer-arith'</B> requests a warning if these extensions
are used.</P>
<HR>
<H2><A NAME="SEC80"><U>Non-Constant Initializers</U></A></H2>
<P>As in standard C++ and ISO C99, the elements of an aggregate initializer for an
automatic variable are not required to be constant expressions in GNU C.
Here is an example of an initializer with run-time varying elements:</P>
<PRE>void foo (float f, float g)
{
float beat_freqs[2] = { f-g, f+g };
/* ... */
}
</PRE>
<HR>
<H2><A NAME="SEC81"><U>Compound Literals (Cast Constructors)</U></A></H2>
<P>ISO C99 supports compound literals. A compound literal looks like
a cast containing an initializer. Its value is an object of the
type specified in the cast, containing the elements specified in
the initializer; it is an lvalue. As an extension, GCC supports
compound literals in C89 mode and in C++.
<BR><BR>
Usually, the specified type is a structure. Assume that
<CODE><A HREF="keywords.html#struct">struct</A> foo</CODE> and <I>structure</I> are declared as shown:</P>
<PRE>struct foo {int a; char b[2];} structure;
</PRE>
<P>Here is an example of constructing a <CODE><A HREF="keywords.html#struct">struct</A> foo</CODE> with a compound literal:</P>
<PRE>structure = ((struct foo) {x + y, 'a', 0});
</PRE>
<P>This is equivalent to writing the following:</P>
<PRE>{
struct foo temp = {x + y, 'a', 0};
structure = temp;
}
</PRE>
<P>You can also construct an array. If all the elements of the compound literal
are (made up of) simple constant expressions, suitable for use in
initializers of objects of static storage duration, then the compound
literal can be coerced to a pointer to its first element and used in
such an initializer, as shown here:</P>
<PRE>char **foo = (char *[]) { "x", "y", "z" };
</PRE>
<P>Compound literals for scalar types and union types are
also allowed, but then the compound literal is equivalent
to a cast.
<BR><BR>
As a GNU extension, GCC allows initialization of objects with static storage
duration by compound literals (which is not possible in ISO C99, because
the initializer is not a constant).
It is handled as if the object was initialized only with the bracket
enclosed list if compound literal's and object types match.
The initializer list of the compound literal must be constant.
If the object being initialized has array type of unknown size, the size is
determined by compound literal size.</P>
<PRE>static struct foo x = (struct foo) {1, 'a', 'b'};
static int y[] = (int []) {1, 2, 3};
static int z[] = (int [3]) {1};
</PRE>
<P>The above lines are equivalent to the following:</P>
<PRE>static struct foo x = {1, 'a', 'b'};
static int y[] = {1, 2, 3};
static int z[] = {1, 0, 0};
</PRE>
<HR>
<H2><A NAME="SEC82"><U>Designated Initializers</U></A></H2>
<P>Standard C89 requires the elements of an initializer to appear in a fixed
order, the same as the order of the elements in the array or structure
being initialized.
<BR><BR>
In ISO C99 you can give the elements in any order, specifying the array
indices or structure field names they apply to, and GNU C allows this as
an extension in C89 mode as well.
<BR><BR>
To specify an array index, write
<CODE>[<I>index</I>] =</CODE> before the element value. For example,</P>
<PRE>int a[6] = { [4] = 29, [2] = 15 };
</PRE>
<P>is equivalent to</P>
<PRE>int a[6] = { 0, 0, 15, 0, 29, 0 };
</PRE>
<P>The index values must be constant expressions, even if the array being
initialized is automatic.
<BR><BR>
An alternative syntax for this which has been obsolete since GCC 2.5 but
GCC still accepts is to write <CODE>[<I>index</I>]</CODE> before the element
value, with no <CODE>=</CODE>.
<BR><BR>
To initialize a range of elements to the same value, write
<CODE>[<I>first</I> ... <I>last</I>] = <I>value</I></CODE>. This is a GNU
extension. For example,</P>
<PRE>int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };