-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathextend.texi
16121 lines (13690 loc) · 631 KB
/
extend.texi
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
@c Copyright (C) 1988-2013 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
@node C Extensions
@chapter Extensions to the C Language Family
@cindex extensions, C language
@cindex C language extensions
@opindex pedantic
GNU C provides several language features not found in ISO standard C@.
(The @option{-pedantic} option directs GCC to print a warning message if
any of these features is used.) To test for the availability of these
features in conditional compilation, check for a predefined macro
@code{__GNUC__}, which is always defined under GCC@.
These extensions are available in C and Objective-C@. Most of them are
also available in C++. @xref{C++ Extensions,,Extensions to the
C++ Language}, for extensions that apply @emph{only} to C++.
Some features that are in ISO C99 but not C90 or C++ are also, as
extensions, accepted by GCC in C90 mode and in C++.
@menu
* Statement Exprs:: Putting statements and declarations inside expressions.
* Local Labels:: Labels local to a block.
* Labels as Values:: Getting pointers to labels, and computed gotos.
* Nested Functions:: As in Algol and Pascal, lexical scoping of functions.
* Constructing Calls:: Dispatching a call to another function.
* Typeof:: @code{typeof}: referring to the type of an expression.
* Conditionals:: Omitting the middle operand of a @samp{?:} expression.
* Long Long:: Double-word integers---@code{long long int}.
* __int128:: 128-bit integers---@code{__int128}.
* Complex:: Data types for complex numbers.
* Floating Types:: Additional Floating Types.
* Half-Precision:: Half-Precision Floating Point.
* Decimal Float:: Decimal Floating Types.
* Hex Floats:: Hexadecimal floating-point constants.
* Fixed-Point:: Fixed-Point Types.
* Named Address Spaces::Named address spaces.
* Zero Length:: Zero-length arrays.
* Variable Length:: Arrays whose length is computed at run time.
* Empty Structures:: Structures with no members.
* Variadic Macros:: Macros with a variable number of arguments.
* Escaped Newlines:: Slightly looser rules for escaped newlines.
* Subscripting:: Any array can be subscripted, even if not an lvalue.
* Pointer Arith:: Arithmetic on @code{void}-pointers and function pointers.
* Initializers:: Non-constant initializers.
* Compound Literals:: Compound literals give structures, unions
or arrays as values.
* Designated Inits:: Labeling elements of initializers.
* Cast to Union:: Casting to union type from any member of the union.
* Case Ranges:: `case 1 ... 9' and such.
* Mixed Declarations:: Mixing declarations and code.
* Function Attributes:: Declaring that functions have no side effects,
or that they can never return.
* Attribute Syntax:: Formal syntax for attributes.
* Function Prototypes:: Prototype declarations and old-style definitions.
* C++ Comments:: C++ comments are recognized.
* Dollar Signs:: Dollar sign is allowed in identifiers.
* Character Escapes:: @samp{\e} stands for the character @key{ESC}.
* Variable Attributes:: Specifying attributes of variables.
* Type Attributes:: Specifying attributes of types.
* Alignment:: Inquiring about the alignment of a type or variable.
* Inline:: Defining inline functions (as fast as macros).
* Volatiles:: What constitutes an access to a volatile object.
* Extended Asm:: Assembler instructions with C expressions as operands.
(With them you can define ``built-in'' functions.)
* Constraints:: Constraints for asm operands
* Asm Labels:: Specifying the assembler name to use for a C symbol.
* Explicit Reg Vars:: Defining variables residing in specified registers.
* Alternate Keywords:: @code{__const__}, @code{__asm__}, etc., for header files.
* Incomplete Enums:: @code{enum foo;}, with details to follow.
* Function Names:: Printable strings which are the name of the current
function.
* Return Address:: Getting the return or frame address of a function.
* Vector Extensions:: Using vector instructions through built-in functions.
* Offsetof:: Special syntax for implementing @code{offsetof}.
* __sync Builtins:: Legacy built-in functions for atomic memory access.
* __atomic Builtins:: Atomic built-in functions with memory model.
* Object Size Checking:: Built-in functions for limited buffer overflow
checking.
* Other Builtins:: Other built-in functions.
* Target Builtins:: Built-in functions specific to particular targets.
* Target Format Checks:: Format checks specific to particular targets.
* Pragmas:: Pragmas accepted by GCC.
* Unnamed Fields:: Unnamed struct/union fields within structs/unions.
* Thread-Local:: Per-thread variables.
* Binary constants:: Binary constants using the @samp{0b} prefix.
@end menu
@node Statement Exprs
@section Statements and Declarations in Expressions
@cindex statements inside expressions
@cindex declarations inside expressions
@cindex expressions containing statements
@cindex macros, statements in expressions
@c the above section title wrapped and causes an underfull hbox.. i
@c changed it from "within" to "in". --mew 4feb93
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.
Recall that a compound statement is a sequence of statements surrounded
by braces; in this construct, parentheses go around the braces. For
example:
@smallexample
(@{ int y = foo (); int z;
if (y > 0) z = y;
else z = - y;
z; @})
@end smallexample
@noindent
is a valid (though slightly more complex than necessary) expression
for the absolute value of @code{foo ()}.
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{void}, and thus
effectively no value.)
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:
@smallexample
#define max(a,b) ((a) > (b) ? (a) : (b))
@end smallexample
@noindent
@cindex side effects, macro argument
But this definition computes either @var{a} or @var{b} twice, with bad
results if the operand has side effects. In GNU C, if you know the
type of the operands (here taken as @code{int}), you can define
the macro safely as follows:
@smallexample
#define maxint(a,b) \
(@{int _a = (a), _b = (b); _a > _b ? _a : _b; @})
@end smallexample
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.
If you don't know the type of the operand, you can still do this, but you
must use @code{typeof} (@pxref{Typeof}).
In G++, the result value of a statement expression undergoes array and
function pointer decay, and is returned by value to the enclosing
expression. For instance, if @code{A} is a class, then
@smallexample
A a;
(@{a;@}).Foo ()
@end smallexample
@noindent
constructs a temporary @code{A} object to hold the result of the
statement expression, and that is used to invoke @code{Foo}.
Therefore the @code{this} pointer observed by @code{Foo} is not the
address of @code{a}.
In a statement expression, any temporaries created within a statement
are destroyed at that statement's end. This makes statement
expressions inside macros slightly different from function calls. In
the latter case temporaries introduced during argument evaluation are
destroyed at the end of the statement that includes the function
call. In the statement expression case they are destroyed during
the statement expression. For instance,
@smallexample
#define macro(a) (@{__typeof__(a) b = (a); b + 3; @})
template<typename T> T function(T a) @{ T b = a; return b + 3; @}
void foo ()
@{
macro (X ());
function (X ());
@}
@end smallexample
@noindent
has different places where temporaries are destroyed. For the
@code{macro} case, the temporary @code{X} is destroyed just after
the initialization of @code{b}. In the @code{function} case that
temporary is destroyed when the function returns.
These considerations mean that it is probably a bad idea to use
statement expressions of this form in header files that are designed to
work with C++. (Note that some versions of the GNU C Library contained
header files using statement expressions that lead to precisely this
bug.)
Jumping into a statement expression with @code{goto} or using a
@code{switch} statement outside the statement expression with a
@code{case} or @code{default} label inside the statement expression is
not permitted. Jumping into a statement expression with a computed
@code{goto} (@pxref{Labels as Values}) has undefined behavior.
Jumping out of a statement expression is permitted, but if the
statement expression is part of a larger expression then it is
unspecified which other subexpressions of that expression have been
evaluated except where the language definition requires certain
subexpressions to be evaluated before or after the statement
expression. In any case, as with a function call, the evaluation of a
statement expression is not interleaved with the evaluation of other
parts of the containing expression. For example,
@smallexample
foo (), ((@{ bar1 (); goto a; 0; @}) + bar2 ()), baz();
@end smallexample
@noindent
calls @code{foo} and @code{bar1} and does not call @code{baz} but
may or may not call @code{bar2}. If @code{bar2} is called, it is
called after @code{foo} and before @code{bar1}.
@node Local Labels
@section Locally Declared Labels
@cindex local labels
@cindex macros, local labels
GCC allows you to declare @dfn{local labels} in any nested block
scope. A local label is just like an ordinary label, but you can
only reference it (with a @code{goto} statement, or by taking its
address) within the block in which it is declared.
A local label declaration looks like this:
@smallexample
__label__ @var{label};
@end smallexample
@noindent
or
@smallexample
__label__ @var{label1}, @var{label2}, /* @r{@dots{}} */;
@end smallexample
Local label declarations must come at the beginning of the block,
before any ordinary declarations or statements.
The label declaration defines the label @emph{name}, but does not define
the label itself. You must do this in the usual way, with
@code{@var{label}:}, within the statements of the statement expression.
The local label feature is useful for complex macros. If a macro
contains nested loops, a @code{goto} 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 is multiply defined in that function. A
local label avoids this problem. For example:
@smallexample
#define SEARCH(value, array, target) \
do @{ \
__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:; \
@} while (0)
@end smallexample
This could also be written using a statement expression:
@smallexample
#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; \
@})
@end smallexample
Local label declarations also make the labels they declare visible to
nested functions, if there are any. @xref{Nested Functions}, for details.
@node Labels as Values
@section Labels as Values
@cindex labels as values
@cindex computed gotos
@cindex goto with computed label
@cindex address of a label
You can get the address of a label defined in the current function
(or a containing function) with the unary operator @samp{&&}. The
value has type @code{void *}. This value is a constant and can be used
wherever a constant of that type is valid. For example:
@smallexample
void *ptr;
/* @r{@dots{}} */
ptr = &&foo;
@end smallexample
To use these values, you need to be able to jump to one. This is done
with the computed goto statement@footnote{The analogous feature in
Fortran is called an assigned goto, but that name seems inappropriate in
C, where one can do more than simply store label addresses in label
variables.}, @code{goto *@var{exp};}. For example,
@smallexample
goto *ptr;
@end smallexample
@noindent
Any expression of type @code{void *} is allowed.
One way of using these constants is in initializing a static array that
serves as a jump table:
@smallexample
static void *array[] = @{ &&foo, &&bar, &&hack @};
@end smallexample
@noindent
Then you can select a label with indexing, like this:
@smallexample
goto *array[i];
@end smallexample
@noindent
Note that this does not check whether the subscript is in bounds---array
indexing in C never does that.
Such an array of label values serves a purpose much like that of the
@code{switch} statement. The @code{switch} statement is cleaner, so
use that rather than an array unless the problem does not fit a
@code{switch} statement very well.
Another use of label values is in an interpreter for threaded code.
The labels within the interpreter function can be stored in the
threaded code for super-fast dispatching.
You may not use this mechanism to jump to code in a different function.
If you do that, totally unpredictable things happen. The best way to
avoid this is to store the label address only in automatic variables and
never pass it as an argument.
An alternate way to write the above example is
@smallexample
static const int array[] = @{ &&foo - &&foo, &&bar - &&foo,
&&hack - &&foo @};
goto *(&&foo + array[i]);
@end smallexample
@noindent
This is more friendly to code living in shared libraries, as it reduces
the number of dynamic relocations that are needed, and by consequence,
allows the data to be read-only.
The @code{&&foo} expressions for the same label might have different
values if the containing function is inlined or cloned. If a program
relies on them being always the same,
@code{__attribute__((__noinline__,__noclone__))} should be used to
prevent inlining and cloning. If @code{&&foo} is used in a static
variable initializer, inlining and cloning is forbidden.
@node Nested Functions
@section Nested Functions
@cindex nested functions
@cindex downward funargs
@cindex thunks
A @dfn{nested function} is a function defined inside another function.
Nested functions are supported as an extension in GNU C, but are not
supported by GNU C++.
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}, and
call it twice:
@smallexample
@group
foo (double a, double b)
@{
double square (double z) @{ return z * z; @}
return square (a) + square (b);
@}
@end group
@end smallexample
The nested function can access all the variables of the containing
function that are visible at the point of its definition. This is
called @dfn{lexical scoping}. For example, here we show a nested
function which uses an inherited variable named @code{offset}:
@smallexample
@group
bar (int *array, int offset, int size)
@{
int access (int *array, int index)
@{ return array[index + offset]; @}
int i;
/* @r{@dots{}} */
for (i = 0; i < size; i++)
/* @r{@dots{}} */ access (array, i) /* @r{@dots{}} */
@}
@end group
@end smallexample
Nested function definitions are permitted within functions in the places
where variable definitions are allowed; that is, in any block, mixed
with the other declarations and statements in the block.
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:
@smallexample
hack (int *array, int size)
@{
void store (int index, int value)
@{ array[index] = value; @}
intermediate (store, size);
@}
@end smallexample
Here, the function @code{intermediate} receives the address of
@code{store} as an argument. If @code{intermediate} calls @code{store},
the arguments given to @code{store} are used to store into @code{array}.
But this technique works only so long as the containing function
(@code{hack}, in this example) does not exit.
If you try to call the nested function through its address after the
containing function exits, all hell breaks loose. If you try
to call it after a containing scope level exits, 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.
GCC implements taking the address of a nested function using a technique
called @dfn{trampolines}. This technique was described in
@cite{Lexical Closures for C++} (Thomas M. Breuel, USENIX
C++ Conference Proceedings, October 17-21, 1988).
A nested function can jump to a label inherited from a containing
function, provided the label is explicitly declared in the containing
function (@pxref{Local Labels}). Such a jump returns instantly to the
containing function, exiting the nested function that did the
@code{goto} and any intermediate functions as well. Here is an example:
@smallexample
@group
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;
/* @r{@dots{}} */
for (i = 0; i < size; i++)
/* @r{@dots{}} */ access (array, i) /* @r{@dots{}} */
/* @r{@dots{}} */
return 0;
/* @r{Control comes here from @code{access}
if it detects an error.} */
failure:
return -1;
@}
@end group
@end smallexample
A nested function always has no linkage. Declaring one with
@code{extern} or @code{static} is erroneous. If you need to declare the nested function
before its definition, use @code{auto} (which is otherwise meaningless
for function declarations).
@smallexample
bar (int *array, int offset, int size)
@{
__label__ failure;
auto int access (int *, int);
/* @r{@dots{}} */
int access (int *array, int index)
@{
if (index > size)
goto failure;
return array[index + offset];
@}
/* @r{@dots{}} */
@}
@end smallexample
@node Constructing Calls
@section Constructing Function Calls
@cindex constructing calls
@cindex forwarding calls
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.
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).
However, these built-in functions may interact badly with some
sophisticated features or other extensions of the language. It
is, therefore, not recommended to use them outside very simple
functions acting as mere forwarders for their arguments.
@deftypefn {Built-in Function} {void *} __builtin_apply_args ()
This built-in function returns a pointer to data
describing how to perform a call with the same arguments as are passed
to the current function.
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.
@end deftypefn
@deftypefn {Built-in Function} {void *} __builtin_apply (void (*@var{function})(), void *@var{arguments}, size_t @var{size})
This built-in function invokes @var{function}
with a copy of the parameters described by @var{arguments}
and @var{size}.
The value of @var{arguments} should be the value returned by
@code{__builtin_apply_args}. The argument @var{size} specifies the size
of the stack argument data, in bytes.
This function returns a pointer to data describing
how to return whatever value is returned by @var{function}. The data
is saved in a block of memory allocated on the stack.
It is not always simple to compute the proper value for @var{size}. The
value is used by @code{__builtin_apply} to compute the amount of data
that should be pushed on the stack and copied from the incoming argument
area.
@end deftypefn
@deftypefn {Built-in Function} {void} __builtin_return (void *@var{result})
This built-in function returns the value described by @var{result} from
the containing function. You should specify, for @var{result}, a value
returned by @code{__builtin_apply}.
@end deftypefn
@deftypefn {Built-in Function} {} __builtin_va_arg_pack ()
This built-in function represents all anonymous arguments of an inline
function. It can be used only in inline functions that are always
inlined, never compiled as a separate function, such as those using
@code{__attribute__ ((__always_inline__))} or
@code{__attribute__ ((__gnu_inline__))} extern inline functions.
It must be only passed as last argument to some other function
with variable arguments. This is useful for writing small wrapper
inlines for variable argument functions, when using preprocessor
macros is undesirable. For example:
@smallexample
extern int myprintf (FILE *f, const char *format, ...);
extern inline __attribute__ ((__gnu_inline__)) int
myprintf (FILE *f, const char *format, ...)
@{
int r = fprintf (f, "myprintf: ");
if (r < 0)
return r;
int s = fprintf (f, format, __builtin_va_arg_pack ());
if (s < 0)
return s;
return r + s;
@}
@end smallexample
@end deftypefn
@deftypefn {Built-in Function} {size_t} __builtin_va_arg_pack_len ()
This built-in function returns the number of anonymous arguments of
an inline function. It can be used only in inline functions that
are always inlined, never compiled as a separate function, such
as those using @code{__attribute__ ((__always_inline__))} or
@code{__attribute__ ((__gnu_inline__))} extern inline functions.
For example following does link- or run-time checking of open
arguments for optimized code:
@smallexample
#ifdef __OPTIMIZE__
extern inline __attribute__((__gnu_inline__)) int
myopen (const char *path, int oflag, ...)
@{
if (__builtin_va_arg_pack_len () > 1)
warn_open_too_many_arguments ();
if (__builtin_constant_p (oflag))
@{
if ((oflag & O_CREAT) != 0 && __builtin_va_arg_pack_len () < 1)
@{
warn_open_missing_mode ();
return __open_2 (path, oflag);
@}
return open (path, oflag, __builtin_va_arg_pack ());
@}
if (__builtin_va_arg_pack_len () < 1)
return __open_2 (path, oflag);
return open (path, oflag, __builtin_va_arg_pack ());
@}
#endif
@end smallexample
@end deftypefn
@node Typeof
@section Referring to a Type with @code{typeof}
@findex typeof
@findex sizeof
@cindex macros, types of arguments
Another way to refer to the type of an expression is with @code{typeof}.
The syntax of using of this keyword looks like @code{sizeof}, but the
construct acts semantically like a type name defined with @code{typedef}.
There are two ways of writing the argument to @code{typeof}: with an
expression or with a type. Here is an example with an expression:
@smallexample
typeof (x[0](1))
@end smallexample
@noindent
This assumes that @code{x} is an array of pointers to functions;
the type described is that of the values of the functions.
Here is an example with a typename as the argument:
@smallexample
typeof (int *)
@end smallexample
@noindent
Here the type described is that of pointers to @code{int}.
If you are writing a header file that must work when included in ISO C
programs, write @code{__typeof__} instead of @code{typeof}.
@xref{Alternate Keywords}.
A @code{typeof} construct can be used anywhere a typedef name can be
used. For example, you can use it in a declaration, in a cast, or inside
of @code{sizeof} or @code{typeof}.
The operand of @code{typeof} is evaluated for its side effects if and
only if it is an expression of variably modified type or the name of
such a type.
@code{typeof} is often useful in conjunction with
statement expressions (@pxref{Statement Exprs}).
Here is how the two together can
be used to define a safe ``maximum'' macro which operates on any
arithmetic type and evaluates each of its arguments exactly once:
@smallexample
#define max(a,b) \
(@{ typeof (a) _a = (a); \
typeof (b) _b = (b); \
_a > _b ? _a : _b; @})
@end smallexample
@cindex underscores in variables in macros
@cindex @samp{_} in variables in macros
@cindex local variables in macros
@cindex variables, local, in macros
@cindex macros, local variables in
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} and @code{b}. 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.
@noindent
Some more examples of the use of @code{typeof}:
@itemize @bullet
@item
This declares @code{y} with the type of what @code{x} points to.
@smallexample
typeof (*x) y;
@end smallexample
@item
This declares @code{y} as an array of such values.
@smallexample
typeof (*x) y[4];
@end smallexample
@item
This declares @code{y} as an array of pointers to characters:
@smallexample
typeof (typeof (char *)[4]) y;
@end smallexample
@noindent
It is equivalent to the following traditional C declaration:
@smallexample
char *y[4];
@end smallexample
To see the meaning of the declaration using @code{typeof}, and why it
might be a useful way to write, rewrite it with these macros:
@smallexample
#define pointer(T) typeof(T *)
#define array(T, N) typeof(T [N])
@end smallexample
@noindent
Now the declaration can be rewritten this way:
@smallexample
array (pointer (char), 4) y;
@end smallexample
@noindent
Thus, @code{array (pointer (char), 4)} is the type of arrays of 4
pointers to @code{char}.
@end itemize
@emph{Compatibility Note:} In addition to @code{typeof}, GCC 2 supported
a more limited extension that permitted one to write
@smallexample
typedef @var{T} = @var{expr};
@end smallexample
@noindent
with the effect of declaring @var{T} to have the type of the expression
@var{expr}. This extension does not work with GCC 3 (versions between
3.0 and 3.2 crash; 3.2.1 and later give an error). Code that
relies on it should be rewritten to use @code{typeof}:
@smallexample
typedef typeof(@var{expr}) @var{T};
@end smallexample
@noindent
This works with all versions of GCC@.
@node Conditionals
@section Conditionals with Omitted Operands
@cindex conditional expressions, extensions
@cindex omitted middle-operands
@cindex middle-operands, omitted
@cindex extensions, @code{?:}
@cindex @code{?:} extensions
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.
Therefore, the expression
@smallexample
x ? : y
@end smallexample
@noindent
has the value of @code{x} if that is nonzero; otherwise, the value of
@code{y}.
This example is perfectly equivalent to
@smallexample
x ? x : y
@end smallexample
@cindex side effect in @code{?:}
@cindex @code{?:} side effect
@noindent
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.
@node __int128
@section 128-bit integers
@cindex @code{__int128} data types
As an extension the integer scalar type @code{__int128} is supported for
targets which have an integer mode wide enough to hold 128 bits.
Simply write @code{__int128} for a signed 128-bit integer, or
@code{unsigned __int128} for an unsigned 128-bit integer. There is no
support in GCC for expressing an integer constant of type @code{__int128}
for targets with @code{long long} integer less than 128 bits wide.
@node Long Long
@section Double-Word Integers
@cindex @code{long long} data types
@cindex double-word arithmetic
@cindex multiprecision arithmetic
@cindex @code{LL} integer suffix
@cindex @code{ULL} integer suffix
ISO C99 supports data types for integers that are at least 64 bits wide,
and as an extension GCC supports them in C90 mode and in C++.
Simply write @code{long long int} for a signed integer, or
@code{unsigned long long int} for an unsigned integer. To make an
integer constant of type @code{long long int}, add the suffix @samp{LL}
to the integer. To make an integer constant of type @code{unsigned long
long int}, add the suffix @samp{ULL} to the integer.
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. Multiplication is open-coded
if the machine supports a fullword-to-doubleword widening multiply
instruction. Division and shifts are open-coded only on machines that
provide special support. The operations that are not open-coded use
special library routines that come with GCC@.
There may be pitfalls when you use @code{long long} types for function
arguments without function prototypes. If a function
expects type @code{int} for its argument, and you pass a value of type
@code{long long int}, confusion results because the caller and the
subroutine disagree about the number of bytes for the argument.
Likewise, if the function expects @code{long long int} and you pass
@code{int}. The best way to avoid such problems is to use prototypes.
@node Complex
@section Complex Numbers
@cindex complex numbers
@cindex @code{_Complex} keyword
@cindex @code{__complex__} keyword
ISO C99 supports complex floating data types, and as an extension GCC
supports them in C90 mode and in C++. GCC also supports complex integer data
types which are not part of ISO C99. You can declare complex types
using the keyword @code{_Complex}. As an extension, the older GNU
keyword @code{__complex__} is also supported.
For example, @samp{_Complex double x;} declares @code{x} as a
variable whose real part and imaginary part are both of type
@code{double}. @samp{_Complex short int y;} declares @code{y} to
have real and imaginary parts of type @code{short int}; this is not
likely to be useful, but it shows that the set of complex types is
complete.
To write a constant with a complex data type, use the suffix @samp{i} or
@samp{j} (either one; they are equivalent). For example, @code{2.5fi}
has type @code{_Complex float} and @code{3i} has type
@code{_Complex int}. 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; if you have an ISO C99
conforming C library (such as the GNU C Library), and want to construct complex
constants of floating type, you should include @code{<complex.h>} and
use the macros @code{I} or @code{_Complex_I} instead.
@cindex @code{__real__} keyword
@cindex @code{__imag__} keyword
To extract the real part of a complex-valued expression @var{exp}, write
@code{__real__ @var{exp}}. Likewise, use @code{__imag__} 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{creal}, @code{creall}, @code{cimagf}, @code{cimag} and
@code{cimagl}, declared in @code{<complex.h>} and also provided as
built-in functions by GCC@.
@cindex complex conjugation
The operator @samp{~} 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{conj} and @code{conjl}, declared in @code{<complex.h>} and also
provided as built-in functions by GCC@.
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). Only the DWARF 2
debug info format can represent this, so use of DWARF 2 is recommended.
If you are using the stabs debug info format, GCC describes a noncontiguous
complex variable as if it were two separate variables of noncomplex type.
If the variable's actual name is @code{foo}, the two fictitious
variables are named @code{foo$real} and @code{foo$imag}. You can
examine and set these two fictitious variables with your debugger.
@node Floating Types
@section Additional Floating Types
@cindex additional floating types
@cindex @code{__float80} data type
@cindex @code{__float128} data type
@cindex @code{w} floating point suffix
@cindex @code{q} floating point suffix
@cindex @code{W} floating point suffix
@cindex @code{Q} floating point suffix
As an extension, GNU C supports additional floating
types, @code{__float80} and @code{__float128} to support 80-bit
(@code{XFmode}) and 128-bit (@code{TFmode}) floating types.
Support for additional types includes the arithmetic operators:
add, subtract, multiply, divide; unary arithmetic operators;
relational operators; equality operators; and conversions to and from
integer and other floating types. Use a suffix @samp{w} or @samp{W}
in a literal constant of type @code{__float80} and @samp{q} or @samp{Q}
for @code{_float128}. You can declare complex types using the
corresponding internal complex type, @code{XCmode} for @code{__float80}
type and @code{TCmode} for @code{__float128} type:
@smallexample
typedef _Complex float __attribute__((mode(TC))) _Complex128;
typedef _Complex float __attribute__((mode(XC))) _Complex80;
@end smallexample
Not all targets support additional floating-point types. @code{__float80}
and @code{__float128} types are supported on i386, x86_64 and IA-64 targets.
The @code{__float128} type is supported on hppa HP-UX targets.
@node Half-Precision
@section Half-Precision Floating Point
@cindex half-precision floating point
@cindex @code{__fp16} data type
On ARM targets, GCC supports half-precision (16-bit) floating point via
the @code{__fp16} type. You must enable this type explicitly
with the @option{-mfp16-format} command-line option in order to use it.
ARM supports two incompatible representations for half-precision
floating-point values. You must choose one of the representations and
use it consistently in your program.
Specifying @option{-mfp16-format=ieee} selects the IEEE 754-2008 format.
This format can represent normalized values in the range of @math{2^{-14}} to 65504.
There are 11 bits of significand precision, approximately 3
decimal digits.
Specifying @option{-mfp16-format=alternative} selects the ARM
alternative format. This representation is similar to the IEEE
format, but does not support infinities or NaNs. Instead, the range
of exponents is extended, so that this format can represent normalized
values in the range of @math{2^{-14}} to 131008.
The @code{__fp16} type is a storage format only. For purposes
of arithmetic and other operations, @code{__fp16} values in C or C++
expressions are automatically promoted to @code{float}. In addition,
you cannot declare a function with a return value or parameters
of type @code{__fp16}.
Note that conversions from @code{double} to @code{__fp16}
involve an intermediate conversion to @code{float}. Because
of rounding, this can sometimes produce a different result than a
direct conversion.
ARM provides hardware support for conversions between
@code{__fp16} and @code{float} values
as an extension to VFP and NEON (Advanced SIMD). GCC generates
code using these hardware instructions if you compile with
options to select an FPU that provides them;
for example, @option{-mfpu=neon-fp16 -mfloat-abi=softfp},
in addition to the @option{-mfp16-format} option to select
a half-precision format.
Language-level support for the @code{__fp16} data type is
independent of whether GCC generates code using hardware floating-point
instructions. In cases where hardware support is not specified, GCC
implements conversions between @code{__fp16} and @code{float} values
as library calls.
@node Decimal Float
@section Decimal Floating Types
@cindex decimal floating types
@cindex @code{_Decimal32} data type
@cindex @code{_Decimal64} data type
@cindex @code{_Decimal128} data type
@cindex @code{df} integer suffix
@cindex @code{dd} integer suffix