3873 lines
212 KiB
HTML
3873 lines
212 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on March, 17 2001 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>Using and Porting the GNU Compiler Collection (GCC): C Extensions</TITLE>
|
|
|
|
<META NAME="description" CONTENT="Using and Porting the GNU Compiler Collection (GCC): C Extensions">
|
|
<META NAME="keywords" CONTENT="Using and Porting the GNU Compiler Collection (GCC): C Extensions">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC61"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_3.html#SEC60" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_3.html#SEC60"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC62" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC62"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 4. Extensions to the C Language Family </H1>
|
|
<!--docid::SEC61::-->
|
|
<P>
|
|
|
|
GNU C provides several language features not found in ANSI standard C.
|
|
(The <SAMP>`-pedantic'</SAMP> option directs GNU CC 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__</CODE>, which is always defined under GNU CC.
|
|
</P><P>
|
|
|
|
These extensions are available in C and Objective C. Most of them are
|
|
also available in C++. See section <A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105">Extensions to the C++ Language</A>, for extensions that apply <EM>only</EM> to C++.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC62" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC62">4.1 Statements and Declarations in Expressions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Putting statements and declarations inside expressions.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63">4.2 Locally Declared Labels</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Labels local to a statement-expression.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64">4.3 Labels as Values</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Getting pointers to labels, and computed gotos.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65">4.4 Nested Functions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">As in Algol and Pascal, lexical scoping of functions.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC66" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC66">4.5 Constructing Function Calls</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Dispatching a call to another function.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC67" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC67">4.6 Naming an Expression's Type</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Giving a name to the type of some expression.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC68" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC68">4.7 Referring to a Type with <CODE>typeof</CODE></A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"><CODE>typeof</CODE>: referring to the type of an expression.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC69" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC69">4.8 Generalized Lvalues</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Using <SAMP>`?:'</SAMP>, <SAMP>`,'</SAMP> and casts in lvalues.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC70" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC70">4.9 Conditionals with Omitted Operands</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Omitting the middle operand of a <SAMP>`?:'</SAMP> expression.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC71" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC71">4.10 Double-Word Integers</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Double-word integers---<CODE>long long int</CODE>.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC72" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC72">4.11 Complex Numbers</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Data types for complex numbers.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC73" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC73">4.12 Hex Floats</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Hexadecimal floating-point constants.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC74" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC74">4.13 Arrays of Length Zero</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Zero-length arrays.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC75" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC75">4.14 Arrays of Variable Length</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Arrays whose length is computed at run time.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC76" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC76">4.15 Macros with Variable Numbers of Arguments</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Macros with variable number of arguments.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC77" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC77">4.16 Non-Lvalue Arrays May Have Subscripts</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Any array can be subscripted, even if not an lvalue.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC78" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC78">4.17 Arithmetic on <CODE>void</CODE>- and Function-Pointers</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Arithmetic on <CODE>void</CODE>-pointers and function pointers.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC79" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC79">4.18 Non-Constant Initializers</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Non-constant initializers.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC80" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC80">4.19 Constructor Expressions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Constructor expressions give structures, unions
|
|
or arrays as values.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC81" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC81">4.20 Labeled Elements in Initializers</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Labeling elements of initializers.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC83" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC83">4.22 Cast to a Union Type</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Casting to union type from any member of the union.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC82" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC82">4.21 Case Ranges</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">`case 1 ... 9' and such.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC84" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84">4.23 Declaring Attributes of Functions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Declaring that functions have no side effects,
|
|
or that they can never return.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC85" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC85">4.24 Prototypes and Old-Style Function Definitions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Prototype declarations and old-style definitions.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC86" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC86">4.25 C++ Style Comments</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">C++ comments are recognized.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC87" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC87">4.26 Dollar Signs in Identifier Names</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Dollar sign is allowed in identifiers.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC88" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC88">4.27 The Character <KBD>ESC</KBD> in Constants</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"><SAMP>`\e'</SAMP> stands for the character <KBD>ESC</KBD>.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC90" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC90">4.29 Specifying Attributes of Variables</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Specifying attributes of variables.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC91" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC91">4.30 Specifying Attributes of Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Specifying attributes of types.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC89" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC89">4.28 Inquiring on Alignment of Types or Variables</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Inquiring about the alignment of a type or variable.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC92" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC92">4.31 An Inline Function is As Fast As a Macro</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Defining inline functions (as fast as macros).</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC93" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93">4.32 Assembler Instructions with C Expression Operands</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Assembler instructions with C expressions as operands.</TD></TR>
|
|
</TABLE>
|
|
(With them you can define "built-in" functions.)
|
|
<br>
|
|
<TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC95" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC95">4.33 Controlling Names Used in Assembler Code</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Specifying the assembler name to use for a C symbol.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC96" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC96">4.34 Variables in Specified Registers</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Defining variables residing in specified registers.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99">4.35 Alternate Keywords</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"><CODE>__const__</CODE>, <CODE>__asm__</CODE>, etc., for header files.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC100" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC100">4.36 Incomplete <CODE>enum</CODE> Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"><CODE>enum foo;</CODE>, with details to follow.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC101" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC101">4.37 Function Names as Strings</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Printable strings which are the name of the current
|
|
function.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC102" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC102">4.38 Getting the Return or Frame Address of a Function</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Getting the return or frame address of a function.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC103" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC103">4.39 Other built-in functions provided by GNU CC</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Other built-in functions.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC104" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC104">4.40 Deprecated Features</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Things might disappear from g++.</TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Statement Exprs"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC62"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.1 Statements and Declarations in Expressions </H2>
|
|
<!--docid::SEC62::-->
|
|
<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.
|
|
</P><P>
|
|
|
|
Recall that a compound statement is a sequence of statements surrounded
|
|
by braces; in this construct, parentheses go around the braces. For
|
|
example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>({ int y = foo (); int z;
|
|
if (y > 0) z = y;
|
|
else z = - y;
|
|
z; })
|
|
</pre></td></tr></table></P><P>
|
|
|
|
is a valid (though slightly more complex than necessary) expression
|
|
for the absolute value of <CODE>foo ()</CODE>.
|
|
</P><P>
|
|
|
|
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</CODE>, and thus
|
|
effectively no value.)
|
|
</P><P>
|
|
|
|
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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define max(a,b) ((a) > (b) ? (a) : (b))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX255"></A>
|
|
But this definition computes either <VAR>a</VAR> or <VAR>b</VAR> 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>int</CODE>), you can define
|
|
the macro safely as follows:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define maxint(a,b) \
|
|
({int _a = (a), _b = (b); _a > _b ? _a : _b; })
|
|
</pre></td></tr></table></P><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.
|
|
</P><P>
|
|
|
|
If you don't know the type of the operand, you can still do this, but you
|
|
must use <CODE>typeof</CODE> (see section <A HREF="gcc_4.html#SEC68" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC68">4.7 Referring to a Type with <CODE>typeof</CODE></A>) or type naming (see section <A HREF="gcc_4.html#SEC67" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC67">4.6 Naming an Expression's Type</A>).
|
|
</P><P>
|
|
|
|
<A NAME="Local Labels"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC63"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC62" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC62"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.2 Locally Declared Labels </H2>
|
|
<!--docid::SEC63::-->
|
|
<P>
|
|
|
|
Each statement expression is a scope in which <EM>local labels</EM> can be
|
|
declared. A local label is simply an identifier; you can jump to it
|
|
with an ordinary <CODE>goto</CODE> statement, but only from within the
|
|
statement expression it belongs to.
|
|
</P><P>
|
|
|
|
A local label declaration looks like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>__label__ <VAR>label</VAR>;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
or
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>__label__ <VAR>label1</VAR>, <VAR>label2</VAR>, <small>...</small>;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Local label declarations must come at the beginning of the statement
|
|
expression, right after the <SAMP>`({'</SAMP>, before any ordinary
|
|
declarations.
|
|
</P><P>
|
|
|
|
The label declaration defines the label <EM>name</EM>, but does not define
|
|
the label itself. You must do this in the usual way, with
|
|
<CODE><VAR>label</VAR>:</CODE>, within the statements of the statement expression.
|
|
</P><P>
|
|
|
|
The local label feature is useful because statement expressions are
|
|
often used in macros. If the macro contains nested loops, a <CODE>goto</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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><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></td></tr></table></P><P>
|
|
|
|
<A NAME="Labels as Values"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC64"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.3 Labels as Values </H2>
|
|
<!--docid::SEC64::-->
|
|
<P>
|
|
|
|
You can get the address of a label defined in the current function
|
|
(or a containing function) with the unary operator <SAMP>`&&'</SAMP>. The
|
|
value has type <CODE>void *</CODE>. This value is a constant and can be used
|
|
wherever a constant of that type is valid. For example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>void *ptr;
|
|
<small>...</small>
|
|
ptr = &&foo;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
To use these values, you need to be able to jump to one. This is done
|
|
with the computed goto statement<A NAME="DOCF1" HREF="gcc_fot.html#FOOT1" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_fot.html#FOOT1">(1)</A>, <CODE>goto *<VAR>exp</VAR>;</CODE>. For example,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>goto *ptr;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Any expression of type <CODE>void *</CODE> is allowed.
|
|
</P><P>
|
|
|
|
One way of using these constants is in initializing a static array that
|
|
will serve as a jump table:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>static void *array[] = { &&foo, &&bar, &&hack };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Then you can select a label with indexing, like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>goto *array[i];
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Note that this does not check whether the subscript is in bounds--array
|
|
indexing in C never does that.
|
|
</P><P>
|
|
|
|
Such an array of label values serves a purpose much like that of the
|
|
<CODE>switch</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.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
You can 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.
|
|
</P><P>
|
|
|
|
<A NAME="Nested Functions"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC65"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC66" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC66"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC66" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC66"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.4 Nested Functions </H2>
|
|
<!--docid::SEC65::-->
|
|
<P>
|
|
|
|
A <EM>nested function</EM> is a function defined inside another function.
|
|
(Nested functions are not supported for 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</CODE>, and call it twice:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>foo (double a, double b)
|
|
{
|
|
double square (double z) { return z * z; }
|
|
|
|
return square (a) + square (b);
|
|
}
|
|
</pre></td></tr></table></P><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 <EM>lexical scoping</EM>. For example, here we show a nested
|
|
function which uses an inherited variable named <CODE>offset</CODE>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>bar (int *array, int offset, int size)
|
|
{
|
|
int access (int *array, int index)
|
|
{ return array[index + offset]; }
|
|
int i;
|
|
<small>...</small>
|
|
for (i = 0; i < size; i++)
|
|
<small>...</small> access (array, i) <small>...</small>
|
|
}
|
|
</pre></td></tr></table></P><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.
|
|
</P><P>
|
|
|
|
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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>hack (int *array, int size)
|
|
{
|
|
void store (int index, int value)
|
|
{ array[index] = value; }
|
|
|
|
intermediate (store, size);
|
|
}
|
|
</pre></td></tr></table></P><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.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
GNU CC implements taking the address of a nested function using a
|
|
technique called <EM>trampolines</EM>. A paper describing them is
|
|
available as <SAMP>`http://master.debian.org/~karlheg/Usenix88-lexic.pdf'</SAMP>.
|
|
</P><P>
|
|
|
|
A nested function can jump to a label inherited from a containing
|
|
function, provided the label was explicitly declared in the containing
|
|
function (see section <A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63">4.2 Locally Declared Labels</A>). Such a jump returns instantly to the
|
|
containing function, exiting the nested function which did the
|
|
<CODE>goto</CODE> and any intermediate functions as well. Here is an example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>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;
|
|
<small>...</small>
|
|
for (i = 0; i < size; i++)
|
|
<small>...</small> access (array, i) <small>...</small>
|
|
<small>...</small>
|
|
return 0;
|
|
|
|
/* Control comes here from <CODE>access</CODE>
|
|
if it detects an error. */
|
|
failure:
|
|
return -1;
|
|
}
|
|
</pre></td></tr></table></P><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>auto</CODE> (which is otherwise meaningless
|
|
for function declarations).
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>bar (int *array, int offset, int size)
|
|
{
|
|
__label__ failure;
|
|
auto int access (int *, int);
|
|
<small>...</small>
|
|
int access (int *array, int index)
|
|
{
|
|
if (index > size)
|
|
goto failure;
|
|
return array[index + offset];
|
|
}
|
|
<small>...</small>
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Constructing Calls"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC66"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC67" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC67"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC67" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC67"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.5 Constructing Function Calls </H2>
|
|
<!--docid::SEC66::-->
|
|
<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.
|
|
</P><P>
|
|
|
|
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><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX256"></A>
|
|
<DT><CODE>__builtin_apply_args ()</CODE>
|
|
<DD>This built-in function returns a pointer of type <CODE>void *</CODE> to data
|
|
describing how to perform a call with the same arguments as were passed
|
|
to the current function.
|
|
<P>
|
|
|
|
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><P>
|
|
|
|
<A NAME="IDX257"></A>
|
|
<DT><CODE>__builtin_apply (<VAR>function</VAR>, <VAR>arguments</VAR>, <VAR>size</VAR>)</CODE>
|
|
<DD>This built-in function invokes <VAR>function</VAR> (type <CODE>void (*)()</CODE>)
|
|
with a copy of the parameters described by <VAR>arguments</VAR> (type
|
|
<CODE>void *</CODE>) and <VAR>size</VAR> (type <CODE>int</CODE>).
|
|
<P>
|
|
|
|
The value of <VAR>arguments</VAR> should be the value returned by
|
|
<CODE>__builtin_apply_args</CODE>. The argument <VAR>size</VAR> specifies the size
|
|
of the stack argument data, in bytes.
|
|
</P><P>
|
|
|
|
This function returns a pointer of type <CODE>void *</CODE> to data describing
|
|
how to return whatever value was returned by <VAR>function</VAR>. The data
|
|
is saved in a block of memory allocated on the stack.
|
|
</P><P>
|
|
|
|
It is not always simple to compute the proper value for <VAR>size</VAR>. The
|
|
value is used by <CODE>__builtin_apply</CODE> to compute the amount of data
|
|
that should be pushed on the stack and copied from the incoming argument
|
|
area.
|
|
</P><P>
|
|
|
|
<A NAME="IDX258"></A>
|
|
<DT><CODE>__builtin_return (<VAR>result</VAR>)</CODE>
|
|
<DD>This built-in function returns the value described by <VAR>result</VAR> from
|
|
the containing function. You should specify, for <VAR>result</VAR>, a value
|
|
returned by <CODE>__builtin_apply</CODE>.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Naming Types"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC67"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC66" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC66"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC68" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC68"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC68" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC68"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.6 Naming an Expression's Type </H2>
|
|
<!--docid::SEC67::-->
|
|
<P>
|
|
|
|
You can give a name to the type of an expression using a <CODE>typedef</CODE>
|
|
declaration with an initializer. Here is how to define <VAR>name</VAR> as a
|
|
type name for the type of <VAR>exp</VAR>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>typedef <VAR>name</VAR> = <VAR>exp</VAR>;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This is 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:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define max(a,b) \
|
|
({typedef _ta = (a), _tb = (b); \
|
|
_ta _a = (a); _tb _b = (b); \
|
|
_a > _b ? _a : _b; })
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX259"></A>
|
|
<A NAME="IDX260"></A>
|
|
<A NAME="IDX261"></A>
|
|
<A NAME="IDX262"></A>
|
|
<A NAME="IDX263"></A>
|
|
</P><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.
|
|
</P><P>
|
|
|
|
<A NAME="Typeof"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC68"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC67" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC67"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC69" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC69"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC69" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC69"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.7 Referring to a Type with <CODE>typeof</CODE> </H2>
|
|
<!--docid::SEC68::-->
|
|
<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>sizeof</CODE>, but the
|
|
construct acts semantically like a type name defined with <CODE>typedef</CODE>.
|
|
</P><P>
|
|
|
|
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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>typeof (x[0](1))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This assumes that <CODE>x</CODE> is an array of functions; the type described
|
|
is that of the values of the functions.
|
|
</P><P>
|
|
|
|
Here is an example with a typename as the argument:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>typeof (int *)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here the type described is that of pointers to <CODE>int</CODE>.
|
|
</P><P>
|
|
|
|
If you are writing a header file that must work when included in ANSI C
|
|
programs, write <CODE>__typeof__</CODE> instead of <CODE>typeof</CODE>.
|
|
See section <A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99">4.35 Alternate Keywords</A>.
|
|
</P><P>
|
|
|
|
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>sizeof</CODE> or <CODE>typeof</CODE>.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
This declares <CODE>y</CODE> with the type of what <CODE>x</CODE> points to.
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>typeof (*x) y;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
This declares <CODE>y</CODE> as an array of such values.
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>typeof (*x) y[4];
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
This declares <CODE>y</CODE> as an array of pointers to characters:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>typeof (typeof (char *)[4]) y;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
It is equivalent to the following traditional C declaration:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>char *y[4];
|
|
</pre></td></tr></table></P><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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define pointer(T) typeof(T *)
|
|
#define array(T, N) typeof(T [N])
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Now the declaration can be rewritten this way:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>array (pointer (char), 4) y;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Thus, <CODE>array (pointer (char), 4)</CODE> is the type of arrays of 4
|
|
pointers to <CODE>char</CODE>.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Lvalues"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC69"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC68" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC68"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC70" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC70"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC70" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC70"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.8 Generalized Lvalues </H2>
|
|
<!--docid::SEC69::-->
|
|
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.
|
|
<P>
|
|
|
|
Standard C++ allows compound expressions and conditional expressions as
|
|
lvalues, and permits casts to reference type, so use of this extension
|
|
is deprecated for C++ code.
|
|
</P><P>
|
|
|
|
For example, a compound expression can be assigned, provided the last
|
|
expression in the sequence is an lvalue. These two expressions are
|
|
equivalent:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(a, b) += 5
|
|
a, (b += 5)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Similarly, the address of the compound expression can be taken. These two
|
|
expressions are equivalent:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>&(a, b)
|
|
a, &b
|
|
</pre></td></tr></table></P><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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(a ? b : c) = 5
|
|
(a ? b = 5 : (c = 5))
|
|
</pre></td></tr></table></P><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>char *</CODE>, the following two
|
|
expressions are equivalent:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(int)a = 5
|
|
(int)(a = (char *)(int)5)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
An assignment-with-arithmetic operation such as <SAMP>`+='</SAMP> 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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>(int)a += 5
|
|
(int)(a = (char *)(int) ((int)a + 5))
|
|
</pre></td></tr></table></P><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>float</CODE>. Then the following
|
|
statement would try to store an integer bit-pattern where a floating
|
|
point number belongs:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>*&(int)f = 1;
|
|
</pre></td></tr></table></P><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, we think it is better to prohibit use of <SAMP>`&'</SAMP> on a cast.
|
|
</P><P>
|
|
|
|
If you really do want an <CODE>int *</CODE> pointer with the address of
|
|
<CODE>f</CODE>, you can simply write <CODE>(int *)&f</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="Conditionals"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC70"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC69" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC69"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC71" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC71"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.9 Conditionals with Omitted Operands </H2>
|
|
<!--docid::SEC70::-->
|
|
<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.
|
|
</P><P>
|
|
|
|
Therefore, the expression
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>x ? : y
|
|
</pre></td></tr></table></P><P>
|
|
|
|
has the value of <CODE>x</CODE> if that is nonzero; otherwise, the value of
|
|
<CODE>y</CODE>.
|
|
</P><P>
|
|
|
|
This example is perfectly equivalent to
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>x ? x : y
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX264"></A>
|
|
<A NAME="IDX265"></A>
|
|
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><P>
|
|
|
|
<A NAME="Long Long"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC71"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC70" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC70"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC72" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC72"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.10 Double-Word Integers </H2>
|
|
<!--docid::SEC71::-->
|
|
<P>
|
|
|
|
GNU C supports data types for integers that are twice as long as
|
|
<CODE>int</CODE>. Simply write <CODE>long long int</CODE> for a signed integer, or
|
|
<CODE>unsigned long long int</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.
|
|
</P><P>
|
|
|
|
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 fullword-to-doubleword a 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 GNU CC.
|
|
</P><P>
|
|
|
|
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>int</CODE> for its argument, and you pass a value of type
|
|
<CODE>long long int</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>long long int</CODE> and you pass
|
|
<CODE>int</CODE>. The best way to avoid such problems is to use prototypes.
|
|
</P><P>
|
|
|
|
<A NAME="Complex"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC72"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC71" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC71"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC73" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC73"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.11 Complex Numbers </H2>
|
|
<!--docid::SEC72::-->
|
|
<P>
|
|
|
|
GNU C supports complex data types. You can declare both complex integer
|
|
types and complex floating types, using the keyword <CODE>__complex__</CODE>.
|
|
</P><P>
|
|
|
|
For example, <SAMP>`__complex__ double x;'</SAMP> declares <CODE>x</CODE> as a
|
|
variable whose real part and imaginary part are both of type
|
|
<CODE>double</CODE>. <SAMP>`__complex__ short int y;'</SAMP> declares <CODE>y</CODE> to
|
|
have real and imaginary parts of type <CODE>short int</CODE>; this is not
|
|
likely to be useful, but it shows that the set of complex types is
|
|
complete.
|
|
</P><P>
|
|
|
|
To write a constant with a complex data type, use the suffix <SAMP>`i'</SAMP> or
|
|
<SAMP>`j'</SAMP> (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.
|
|
</P><P>
|
|
|
|
To extract the real part of a complex-valued expression <VAR>exp</VAR>, write
|
|
<CODE>__real__ <VAR>exp</VAR></CODE>. Likewise, use <CODE>__imag__</CODE> to
|
|
extract the imaginary part.
|
|
</P><P>
|
|
|
|
The operator <SAMP>`~'</SAMP> performs complex conjugation when used on a value
|
|
with a complex type.
|
|
</P><P>
|
|
|
|
GNU CC 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). None of the
|
|
supported debugging info formats has a way to represent noncontiguous
|
|
allocation like this, so GNU CC describes a noncontiguous complex
|
|
variable as if it were two separate variables of noncomplex type.
|
|
If the variable's actual name is <CODE>foo</CODE>, the two fictitious
|
|
variables are named <CODE>foo$real</CODE> and <CODE>foo$imag</CODE>. You can
|
|
examine and set these two fictitious variables with your debugger.
|
|
</P><P>
|
|
|
|
A future version of GDB will know how to recognize such pairs and treat
|
|
them as a single variable with a complex type.
|
|
</P><P>
|
|
|
|
<A NAME="Hex Floats"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC73"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC72" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC72"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC74" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC74"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.12 Hex Floats </H2>
|
|
<!--docid::SEC73::-->
|
|
GNU CC recognizes 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. 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 significand part will be multiplied. Thus <CODE>0x1.f</CODE> is
|
|
1 15/16, <CODE>p3</CODE> multiplies it by 8, and the value of <CODE>0x1.fp3</CODE>
|
|
is the same as <CODE>1.55e1</CODE>.
|
|
<P>
|
|
|
|
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>float</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="Zero Length"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC74"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC73" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC73"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC75" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC75"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.13 Arrays of Length Zero </H2>
|
|
<!--docid::SEC74::-->
|
|
<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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct line {
|
|
int length;
|
|
char contents[0];
|
|
};
|
|
|
|
{
|
|
struct line *thisline = (struct line *)
|
|
malloc (sizeof (struct line) + this_length);
|
|
thisline->length = this_length;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
In standard C, you would have to give <CODE>contents</CODE> a length of 1, which
|
|
means either you waste space or complicate the argument to <CODE>malloc</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="Variable Length"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC75"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC74" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC74"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC76" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC76"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.14 Arrays of Variable Length </H2>
|
|
<!--docid::SEC75::-->
|
|
<P>
|
|
|
|
Variable-length automatic arrays are allowed in GNU C. 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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>FILE *
|
|
concat_fopen (char *s1, char *s2, char *mode)
|
|
{
|
|
char str[strlen (s1) + strlen (s2) + 1];
|
|
strcpy (str, s1);
|
|
strcat (str, s2);
|
|
return fopen (str, mode);
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX266"></A>
|
|
<A NAME="IDX267"></A>
|
|
<A NAME="IDX268"></A>
|
|
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.
|
|
</P><P>
|
|
|
|
<A NAME="IDX269"></A>
|
|
You can use the function <CODE>alloca</CODE> to get an effect much like
|
|
variable-length arrays. The function <CODE>alloca</CODE> is available in
|
|
many other C implementations (but not in all). On the other hand,
|
|
variable-length arrays are more elegant.
|
|
</P><P>
|
|
|
|
There are other differences between these two methods. Space allocated
|
|
with <CODE>alloca</CODE> exists until the containing <EM>function</EM> 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
|
|
<CODE>alloca</CODE> in the same function, deallocation of a variable-length array
|
|
will also deallocate anything more recently allocated with <CODE>alloca</CODE>.)
|
|
</P><P>
|
|
|
|
You can also use variable-length arrays as arguments to functions:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct entry
|
|
tester (int len, char data[len][len])
|
|
{
|
|
<small>...</small>
|
|
}
|
|
</pre></td></tr></table></P><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>sizeof</CODE>.
|
|
</P><P>
|
|
|
|
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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct entry
|
|
tester (int len; char data[len][len], int len)
|
|
{
|
|
<small>...</small>
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX270"></A>
|
|
The <SAMP>`int len'</SAMP> before the semicolon is a <EM>parameter forward
|
|
declaration</EM>, and it serves the purpose of making the name <CODE>len</CODE>
|
|
known when the declaration of <CODE>data</CODE> is parsed.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<A NAME="Macro Varargs"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC76"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC75" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC75"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC77" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC77"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.15 Macros with Variable Numbers of Arguments </H2>
|
|
<!--docid::SEC76::-->
|
|
<P>
|
|
|
|
In GNU C, a macro can accept a variable number of arguments, much as a
|
|
function can. The syntax for defining the macro looks much like that
|
|
used for a function. Here is an example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define eprintf(format, args...) \
|
|
fprintf (stderr, format , ## args)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here <CODE>args</CODE> is a <EM>rest argument</EM>: it takes in zero or more
|
|
arguments, as many as the call contains. All of them plus the commas
|
|
between them form the value of <CODE>args</CODE>, which is substituted into
|
|
the macro body where <CODE>args</CODE> is used. Thus, we have this expansion:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>eprintf ("%s:%d: ", input_file_name, line_number)
|
|
==>
|
|
fprintf (stderr, "%s:%d: " , input_file_name, line_number)
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Note that the comma after the string constant comes from the definition
|
|
of <CODE>eprintf</CODE>, whereas the last comma comes from the value of
|
|
<CODE>args</CODE>.
|
|
</P><P>
|
|
|
|
The reason for using <SAMP>`##'</SAMP> is to handle the case when <CODE>args</CODE>
|
|
matches no arguments at all. In this case, <CODE>args</CODE> has an empty
|
|
value. In this case, the second comma in the definition becomes an
|
|
embarrassment: if it got through to the expansion of the macro, we would
|
|
get something like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>fprintf (stderr, "success!\n" , )
|
|
</pre></td></tr></table></P><P>
|
|
|
|
which is invalid C syntax. <SAMP>`##'</SAMP> gets rid of the comma, so we get
|
|
the following instead:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>fprintf (stderr, "success!\n")
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This is a special feature of the GNU C preprocessor: <SAMP>`##'</SAMP> before a
|
|
rest argument that is empty discards the preceding sequence of
|
|
non-whitespace characters from the macro definition. (If another macro
|
|
argument precedes, none of it is discarded.)
|
|
</P><P>
|
|
|
|
It might be better to discard the last preprocessor token instead of the
|
|
last preceding sequence of non-whitespace characters; in fact, we may
|
|
someday change this feature to do so. We advise you to write the macro
|
|
definition so that the preceding sequence of non-whitespace characters
|
|
is just a single token, so that the meaning will not change if we change
|
|
the definition of this feature.
|
|
</P><P>
|
|
|
|
<A NAME="Subscripting"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC77"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC76" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC76"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC78" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC78"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.16 Non-Lvalue Arrays May Have Subscripts </H2>
|
|
<!--docid::SEC77::-->
|
|
<P>
|
|
|
|
<A NAME="IDX271"></A>
|
|
Subscripting is allowed on arrays that are not lvalues, even though the
|
|
unary <SAMP>`&'</SAMP> operator is not. For example, this is valid in GNU C though
|
|
not valid in other C dialects:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct foo {int a[4];};
|
|
|
|
struct foo f();
|
|
|
|
bar (int index)
|
|
{
|
|
return f().a[index];
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Pointer Arith"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC78"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC77" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC77"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC79" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC79"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.17 Arithmetic on <CODE>void</CODE>- and Function-Pointers </H2>
|
|
<!--docid::SEC78::-->
|
|
<P>
|
|
|
|
In GNU C, addition and subtraction operations are supported on pointers to
|
|
<CODE>void</CODE> and on pointers to functions. This is done by treating the
|
|
size of a <CODE>void</CODE> or of a function as 1.
|
|
</P><P>
|
|
|
|
A consequence of this is that <CODE>sizeof</CODE> is also allowed on <CODE>void</CODE>
|
|
and on function types, and returns 1.
|
|
</P><P>
|
|
|
|
The option <SAMP>`-Wpointer-arith'</SAMP> requests a warning if these extensions
|
|
are used.
|
|
</P><P>
|
|
|
|
<A NAME="Initializers"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC79"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC78" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC78"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC80" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC80"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.18 Non-Constant Initializers </H2>
|
|
<!--docid::SEC79::-->
|
|
<P>
|
|
|
|
As in standard C++, 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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>foo (float f, float g)
|
|
{
|
|
float beat_freqs[2] = { f-g, f+g };
|
|
<small>...</small>
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Constructors"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC80"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC79" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC79"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC81" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC81"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC63" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC63"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.19 Constructor Expressions </H2>
|
|
<!--docid::SEC80::-->
|
|
<P>
|
|
|
|
GNU C supports constructor expressions. A constructor 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.
|
|
</P><P>
|
|
|
|
Usually, the specified type is a structure. Assume that
|
|
<CODE>struct foo</CODE> and <CODE>structure</CODE> are declared as shown:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct foo {int a; char b[2];} structure;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here is an example of constructing a <CODE>struct foo</CODE> with a constructor:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>structure = ((struct foo) {x + y, 'a', 0});
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This is equivalent to writing the following:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>{
|
|
struct foo temp = {x + y, 'a', 0};
|
|
structure = temp;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You can also construct an array. If all the elements of the constructor
|
|
are (made up of) simple constant expressions, suitable for use in
|
|
initializers, then the constructor is an lvalue and can be coerced to a
|
|
pointer to its first element, as shown here:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>char **foo = (char *[]) { "x", "y", "z" };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Array constructors whose elements are not simple constants are
|
|
not very useful, because the constructor is not an lvalue. There
|
|
are only two valid ways to use it: to subscript it, or initialize
|
|
an array variable with it. The former is probably slower than a
|
|
<CODE>switch</CODE> statement, while the latter does the same thing an
|
|
ordinary C initializer would do. Here is an example of
|
|
subscripting an array constructor:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>output = ((int[]) { 2, x, 28 }) [input];
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Constructor expressions for scalar types and union types are is
|
|
also allowed, but then the constructor expression is equivalent
|
|
to a cast.
|
|
</P><P>
|
|
|
|
<A NAME="Labeled Elements"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC81"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC80" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC80"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC82" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC82"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.20 Labeled Elements in Initializers </H2>
|
|
<!--docid::SEC81::-->
|
|
<P>
|
|
|
|
Standard C 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.
|
|
</P><P>
|
|
|
|
In GNU C you can give the elements in any order, specifying the array
|
|
indices or structure field names they apply to. This extension is not
|
|
implemented in GNU C++.
|
|
</P><P>
|
|
|
|
To specify an array index, write <SAMP>`[<VAR>index</VAR>]'</SAMP> or
|
|
<SAMP>`[<VAR>index</VAR>] ='</SAMP> before the element value. For example,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int a[6] = { [4] 29, [2] = 15 };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
is equivalent to
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int a[6] = { 0, 0, 15, 0, 29, 0 };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The index values must be constant expressions, even if the array being
|
|
initialized is automatic.
|
|
</P><P>
|
|
|
|
To initialize a range of elements to the same value, write
|
|
<SAMP>`[<VAR>first</VAR> ... <VAR>last</VAR>] = <VAR>value</VAR>'</SAMP>. For example,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Note that the length of the array is the highest value specified
|
|
plus one.
|
|
</P><P>
|
|
|
|
In a structure initializer, specify the name of a field to initialize
|
|
with <SAMP>`<VAR>fieldname</VAR>:'</SAMP> before the element value. For example,
|
|
given the following structure,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct point { int x, y; };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
the following initialization
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct point p = { y: yvalue, x: xvalue };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
is equivalent to
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct point p = { xvalue, yvalue };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Another syntax which has the same meaning is <SAMP>`.<VAR>fieldname</VAR> ='</SAMP>.,
|
|
as shown here:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct point p = { .y = yvalue, .x = xvalue };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You can also use an element label (with either the colon syntax or the
|
|
period-equal syntax) when initializing a union, to specify which element
|
|
of the union should be used. For example,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>union foo { int i; double d; };
|
|
|
|
union foo f = { d: 4 };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
will convert 4 to a <CODE>double</CODE> to store it in the union using
|
|
the second element. By contrast, casting 4 to type <CODE>union foo</CODE>
|
|
would store it into the union as the integer <CODE>i</CODE>, since it is
|
|
an integer. (See section <A HREF="gcc_4.html#SEC83" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC83">4.22 Cast to a Union Type</A>.)
|
|
</P><P>
|
|
|
|
You can combine this technique of naming elements with ordinary C
|
|
initialization of successive elements. Each initializer element that
|
|
does not have a label applies to the next consecutive element of the
|
|
array or structure. For example,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int a[6] = { [1] = v1, v2, [4] = v4 };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
is equivalent to
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int a[6] = { 0, v1, v2, 0, v4, 0 };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Labeling the elements of an array initializer is especially useful
|
|
when the indices are characters or belong to an <CODE>enum</CODE> type.
|
|
For example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int whitespace[256]
|
|
= { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
|
|
['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Case Ranges"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC82"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC81" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC81"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC83" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC83"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.21 Case Ranges </H2>
|
|
<!--docid::SEC82::-->
|
|
<P>
|
|
|
|
You can specify a range of consecutive values in a single <CODE>case</CODE> label,
|
|
like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>case <VAR>low</VAR> ... <VAR>high</VAR>:
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This has the same effect as the proper number of individual <CODE>case</CODE>
|
|
labels, one for each integer value from <VAR>low</VAR> to <VAR>high</VAR>, inclusive.
|
|
</P><P>
|
|
|
|
This feature is especially useful for ranges of ASCII character codes:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>case 'A' ... 'Z':
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<STRONG>Be careful:</STRONG> Write spaces around the <CODE>...</CODE>, for otherwise
|
|
it may be parsed wrong when you use it with integer values. For example,
|
|
write this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>case 1 ... 5:
|
|
</pre></td></tr></table></P><P>
|
|
|
|
rather than this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>case 1...5:
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Cast to Union"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC83"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC82" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC82"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC84" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.22 Cast to a Union Type </H2>
|
|
<!--docid::SEC83::-->
|
|
<P>
|
|
|
|
A cast to union type is similar to other casts, except that the type
|
|
specified is a union type. You can specify the type either with
|
|
<CODE>union <VAR>tag</VAR></CODE> or with a typedef name. A cast to union is actually
|
|
a constructor though, not a cast, and hence does not yield an lvalue like
|
|
normal casts. (See section <A HREF="gcc_4.html#SEC80" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC80">4.19 Constructor Expressions</A>.)
|
|
</P><P>
|
|
|
|
The types that may be cast to the union type are those of the members
|
|
of the union. Thus, given the following union and variables:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>union foo { int i; double d; };
|
|
int x;
|
|
double y;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
both <CODE>x</CODE> and <CODE>y</CODE> can be cast to type <CODE>union</CODE> foo.
|
|
</P><P>
|
|
|
|
Using the cast as the right-hand side of an assignment to a variable of
|
|
union type is equivalent to storing in a member of the union:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>union foo u;
|
|
<small>...</small>
|
|
u = (union foo) x == u.i = x
|
|
u = (union foo) y == u.d = y
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You can also use the union cast as a function argument:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>void hack (union foo);
|
|
<small>...</small>
|
|
hack ((union foo) x);
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Function Attributes"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC84"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC83" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC83"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC85" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC85"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.23 Declaring Attributes of Functions </H2>
|
|
<!--docid::SEC84::-->
|
|
<P>
|
|
|
|
In GNU C, you declare certain things about functions called in your program
|
|
which help the compiler optimize function calls and check your code more
|
|
carefully.
|
|
</P><P>
|
|
|
|
The keyword <CODE>__attribute__</CODE> allows you to specify special
|
|
attributes when making a declaration. This keyword is followed by an
|
|
attribute specification inside double parentheses. Nine attributes,
|
|
<CODE>noreturn</CODE>, <CODE>const</CODE>, <CODE>format</CODE>,
|
|
<CODE>no_instrument_function</CODE>, <CODE>section</CODE>,
|
|
<CODE>constructor</CODE>, <CODE>destructor</CODE>, <CODE>unused</CODE> and <CODE>weak</CODE> are
|
|
currently defined for functions. Other attributes, including
|
|
<CODE>section</CODE> are supported for variables declarations (see section <A HREF="gcc_4.html#SEC90" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC90">4.29 Specifying Attributes of Variables</A>) and for types (see section <A HREF="gcc_4.html#SEC91" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC91">4.30 Specifying Attributes of Types</A>).
|
|
</P><P>
|
|
|
|
You may also specify attributes with <SAMP>`__'</SAMP> preceding and following
|
|
each keyword. This allows you to use them in header files without
|
|
being concerned about a possible macro of the same name. For example,
|
|
you may use <CODE>__noreturn__</CODE> instead of <CODE>noreturn</CODE>.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX272"></A>
|
|
<DT><CODE>noreturn</CODE>
|
|
<DD>A few standard library functions, such as <CODE>abort</CODE> and <CODE>exit</CODE>,
|
|
cannot return. GNU CC knows this automatically. Some programs define
|
|
their own functions that never return. You can declare them
|
|
<CODE>noreturn</CODE> to tell the compiler this fact. For example,
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>void fatal () __attribute__ ((noreturn));
|
|
|
|
void
|
|
fatal (<small>...</small>)
|
|
{
|
|
<small>...</small> /* Print error message. */ <small>...</small>
|
|
exit (1);
|
|
}
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
The <CODE>noreturn</CODE> keyword tells the compiler to assume that
|
|
<CODE>fatal</CODE> cannot return. It can then optimize without regard to what
|
|
would happen if <CODE>fatal</CODE> ever did return. This makes slightly
|
|
better code. More importantly, it helps avoid spurious warnings of
|
|
uninitialized variables.
|
|
</P><P>
|
|
|
|
Do not assume that registers saved by the calling function are
|
|
restored before calling the <CODE>noreturn</CODE> function.
|
|
</P><P>
|
|
|
|
It does not make sense for a <CODE>noreturn</CODE> function to have a return
|
|
type other than <CODE>void</CODE>.
|
|
</P><P>
|
|
|
|
The attribute <CODE>noreturn</CODE> is not implemented in GNU C versions
|
|
earlier than 2.5. An alternative way to declare that a function does
|
|
not return, which works in the current version and in some older
|
|
versions, is as follows:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>typedef void voidfn ();
|
|
|
|
volatile voidfn fatal;
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX273"></A>
|
|
<DT><CODE>const</CODE>
|
|
<DD>Many functions do not examine any values except their arguments, and
|
|
have no effects except the return value. Such a function can be subject
|
|
to common subexpression elimination and loop optimization just as an
|
|
arithmetic operator would be. These functions should be declared
|
|
with the attribute <CODE>const</CODE>. For example,
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>int square (int) __attribute__ ((const));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
says that the hypothetical function <CODE>square</CODE> is safe to call
|
|
fewer times than the program says.
|
|
</P><P>
|
|
|
|
The attribute <CODE>const</CODE> is not implemented in GNU C versions earlier
|
|
than 2.5. An alternative way to declare that a function has no side
|
|
effects, which works in the current version and in some older versions,
|
|
is as follows:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>typedef int intfn ();
|
|
|
|
extern const intfn square;
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
This approach does not work in GNU C++ from 2.6.0 on, since the language
|
|
specifies that the <SAMP>`const'</SAMP> must be attached to the return value.
|
|
</P><P>
|
|
|
|
<A NAME="IDX274"></A>
|
|
Note that a function that has pointer arguments and examines the data
|
|
pointed to must <EM>not</EM> be declared <CODE>const</CODE>. Likewise, a
|
|
function that calls a non-<CODE>const</CODE> function usually must not be
|
|
<CODE>const</CODE>. It does not make sense for a <CODE>const</CODE> function to
|
|
return <CODE>void</CODE>.
|
|
</P><P>
|
|
|
|
<DT><CODE>format (<VAR>archetype</VAR>, <VAR>string-index</VAR>, <VAR>first-to-check</VAR>)</CODE>
|
|
<DD><A NAME="IDX275"></A>
|
|
The <CODE>format</CODE> attribute specifies that a function takes <CODE>printf</CODE>,
|
|
<CODE>scanf</CODE>, or <CODE>strftime</CODE> style arguments which should be type-checked
|
|
against a format string. For example, the declaration:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>extern int
|
|
my_printf (void *my_object, const char *my_format, ...)
|
|
__attribute__ ((format (printf, 2, 3)));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
causes the compiler to check the arguments in calls to <CODE>my_printf</CODE>
|
|
for consistency with the <CODE>printf</CODE> style format string argument
|
|
<CODE>my_format</CODE>.
|
|
</P><P>
|
|
|
|
The parameter <VAR>archetype</VAR> determines how the format string is
|
|
interpreted, and should be either <CODE>printf</CODE>, <CODE>scanf</CODE>, or
|
|
<CODE>strftime</CODE>. The
|
|
parameter <VAR>string-index</VAR> specifies which argument is the format
|
|
string argument (starting from 1), while <VAR>first-to-check</VAR> is the
|
|
number of the first argument to check against the format string. For
|
|
functions where the arguments are not available to be checked (such as
|
|
<CODE>vprintf</CODE>), specify the third parameter as zero. In this case the
|
|
compiler only checks the format string for consistency.
|
|
</P><P>
|
|
|
|
In the example above, the format string (<CODE>my_format</CODE>) is the second
|
|
argument of the function <CODE>my_print</CODE>, and the arguments to check
|
|
start with the third argument, so the correct parameters for the format
|
|
attribute are 2 and 3.
|
|
</P><P>
|
|
|
|
The <CODE>format</CODE> attribute allows you to identify your own functions
|
|
which take format strings as arguments, so that GNU CC can check the
|
|
calls to these functions for errors. The compiler always checks formats
|
|
for the ANSI library functions <CODE>printf</CODE>, <CODE>fprintf</CODE>,
|
|
<CODE>sprintf</CODE>, <CODE>scanf</CODE>, <CODE>fscanf</CODE>, <CODE>sscanf</CODE>, <CODE>strftime</CODE>,
|
|
<CODE>vprintf</CODE>, <CODE>vfprintf</CODE> and <CODE>vsprintf</CODE> whenever such
|
|
warnings are requested (using <SAMP>`-Wformat'</SAMP>), so there is no need to
|
|
modify the header file <TT>`stdio.h'</TT>.
|
|
</P><P>
|
|
|
|
<DT><CODE>format_arg (<VAR>string-index</VAR>)</CODE>
|
|
<DD><A NAME="IDX276"></A>
|
|
The <CODE>format_arg</CODE> attribute specifies that a function takes
|
|
<CODE>printf</CODE> or <CODE>scanf</CODE> style arguments, modifies it (for example,
|
|
to translate it into another language), and passes it to a <CODE>printf</CODE>
|
|
or <CODE>scanf</CODE> style function. For example, the declaration:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>extern char *
|
|
my_dgettext (char *my_domain, const char *my_format)
|
|
__attribute__ ((format_arg (2)));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
causes the compiler to check the arguments in calls to
|
|
<CODE>my_dgettext</CODE> whose result is passed to a <CODE>printf</CODE>,
|
|
<CODE>scanf</CODE>, or <CODE>strftime</CODE> type function for consistency with the
|
|
<CODE>printf</CODE> style format string argument <CODE>my_format</CODE>.
|
|
</P><P>
|
|
|
|
The parameter <VAR>string-index</VAR> specifies which argument is the format
|
|
string argument (starting from 1).
|
|
</P><P>
|
|
|
|
The <CODE>format-arg</CODE> attribute allows you to identify your own
|
|
functions which modify format strings, so that GNU CC can check the
|
|
calls to <CODE>printf</CODE>, <CODE>scanf</CODE>, or <CODE>strftime</CODE> function whose
|
|
operands are a call to one of your own function. The compiler always
|
|
treats <CODE>gettext</CODE>, <CODE>dgettext</CODE>, and <CODE>dcgettext</CODE> in this
|
|
manner.
|
|
</P><P>
|
|
|
|
<DT><CODE>no_instrument_function</CODE>
|
|
<DD><A NAME="IDX277"></A>
|
|
If <SAMP>`-finstrument-functions'</SAMP> is given, profiling function calls will
|
|
be generated at entry and exit of most user-compiled functions.
|
|
Functions with this attribute will not be so instrumented.
|
|
<P>
|
|
|
|
<DT><CODE>section ("section-name")</CODE>
|
|
<DD><A NAME="IDX278"></A>
|
|
Normally, the compiler places the code it generates in the <CODE>text</CODE> section.
|
|
Sometimes, however, you need additional sections, or you need certain
|
|
particular functions to appear in special sections. The <CODE>section</CODE>
|
|
attribute specifies that a function lives in a particular section.
|
|
For example, the declaration:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>extern void foobar (void) __attribute__ ((section ("bar")));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
puts the function <CODE>foobar</CODE> in the <CODE>bar</CODE> section.
|
|
</P><P>
|
|
|
|
Some file formats do not support arbitrary sections so the <CODE>section</CODE>
|
|
attribute is not available on all platforms.
|
|
If you need to map the entire contents of a module to a particular
|
|
section, consider using the facilities of the linker instead.
|
|
</P><P>
|
|
|
|
<DT><CODE>constructor</CODE>
|
|
<DD><DT><CODE>destructor</CODE>
|
|
<DD><A NAME="IDX279"></A>
|
|
<A NAME="IDX280"></A>
|
|
The <CODE>constructor</CODE> attribute causes the function to be called
|
|
automatically before execution enters <CODE>main ()</CODE>. Similarly, the
|
|
<CODE>destructor</CODE> attribute causes the function to be called
|
|
automatically after <CODE>main ()</CODE> has completed or <CODE>exit ()</CODE> has
|
|
been called. Functions with these attributes are useful for
|
|
initializing data that will be used implicitly during the execution of
|
|
the program.
|
|
<P>
|
|
|
|
These attributes are not currently implemented for Objective C.
|
|
</P><P>
|
|
|
|
<DT><CODE>unused</CODE>
|
|
<DD>This attribute, attached to a function, means that the function is meant
|
|
to be possibly unused. GNU CC will not produce a warning for this
|
|
function. GNU C++ does not currently support this attribute as
|
|
definitions without parameters are valid in C++.
|
|
<P>
|
|
|
|
<DT><CODE>weak</CODE>
|
|
<DD><A NAME="IDX281"></A>
|
|
The <CODE>weak</CODE> attribute causes the declaration to be emitted as a weak
|
|
symbol rather than a global. This is primarily useful in defining
|
|
library functions which can be overridden in user code, though it can
|
|
also be used with non-function declarations. Weak symbols are supported
|
|
for ELF targets, and also for a.out targets when using the GNU assembler
|
|
and linker.
|
|
<P>
|
|
|
|
<DT><CODE>alias ("target")</CODE>
|
|
<DD><A NAME="IDX282"></A>
|
|
The <CODE>alias</CODE> attribute causes the declaration to be emitted as an
|
|
alias for another symbol, which must be specified. For instance,
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>void __f () { /* do something */; }
|
|
void f () __attribute__ ((weak, alias ("__f")));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
declares <SAMP>`f'</SAMP> to be a weak alias for <SAMP>`__f'</SAMP>. In C++, the
|
|
mangled name for the target must be used.
|
|
</P><P>
|
|
|
|
Not all target machines support this attribute.
|
|
</P><P>
|
|
|
|
<DT><CODE>no_check_memory_usage</CODE>
|
|
<DD><A NAME="IDX283"></A>
|
|
If <SAMP>`-fcheck-memory-usage'</SAMP> is given, calls to support routines will
|
|
be generated before most memory accesses, to permit support code to
|
|
record usage and detect uses of uninitialized or unallocated storage.
|
|
Since the compiler cannot handle them properly, <CODE>asm</CODE> statements
|
|
are not allowed. Declaring a function with this attribute disables the
|
|
memory checking code for that function, permitting the use of <CODE>asm</CODE>
|
|
statements without requiring separate compilation with different
|
|
options, and allowing you to write support routines of your own if you
|
|
wish, without getting infinite recursion if they get compiled with this
|
|
option.
|
|
<P>
|
|
|
|
<DT><CODE>regparm (<VAR>number</VAR>)</CODE>
|
|
<DD><A NAME="IDX284"></A>
|
|
On the Intel 386, the <CODE>regparm</CODE> attribute causes the compiler to
|
|
pass up to <VAR>number</VAR> integer arguments in registers <VAR>EAX</VAR>,
|
|
<VAR>EDX</VAR>, and <VAR>ECX</VAR> instead of on the stack. Functions that take a
|
|
variable number of arguments will continue to be passed all of their
|
|
arguments on the stack.
|
|
<P>
|
|
|
|
<DT><CODE>stdcall</CODE>
|
|
<DD><A NAME="IDX285"></A>
|
|
On the Intel 386, the <CODE>stdcall</CODE> attribute causes the compiler to
|
|
assume that the called function will pop off the stack space used to
|
|
pass arguments, unless it takes a variable number of arguments.
|
|
<P>
|
|
|
|
The PowerPC compiler for Windows NT currently ignores the <CODE>stdcall</CODE>
|
|
attribute.
|
|
</P><P>
|
|
|
|
<DT><CODE>cdecl</CODE>
|
|
<DD><A NAME="IDX286"></A>
|
|
On the Intel 386, the <CODE>cdecl</CODE> attribute causes the compiler to
|
|
assume that the calling function will pop off the stack space used to
|
|
pass arguments. This is
|
|
useful to override the effects of the <SAMP>`-mrtd'</SAMP> switch.
|
|
<P>
|
|
|
|
The PowerPC compiler for Windows NT currently ignores the <CODE>cdecl</CODE>
|
|
attribute.
|
|
</P><P>
|
|
|
|
<DT><CODE>longcall</CODE>
|
|
<DD><A NAME="IDX287"></A>
|
|
On the RS/6000 and PowerPC, the <CODE>longcall</CODE> attribute causes the
|
|
compiler to always call the function via a pointer, so that functions
|
|
which reside further than 64 megabytes (67,108,864 bytes) from the
|
|
current location can be called.
|
|
<P>
|
|
|
|
<DT><CODE>dllimport</CODE>
|
|
<DD><A NAME="IDX288"></A>
|
|
On the PowerPC running Windows NT, the <CODE>dllimport</CODE> attribute causes
|
|
the compiler to call the function via a global pointer to the function
|
|
pointer that is set up by the Windows NT dll library. The pointer name
|
|
is formed by combining <CODE>__imp_</CODE> and the function name.
|
|
<P>
|
|
|
|
<DT><CODE>dllexport</CODE>
|
|
<DD><A NAME="IDX289"></A>
|
|
On the PowerPC running Windows NT, the <CODE>dllexport</CODE> attribute causes
|
|
the compiler to provide a global pointer to the function pointer, so
|
|
that it can be called with the <CODE>dllimport</CODE> attribute. The pointer
|
|
name is formed by combining <CODE>__imp_</CODE> and the function name.
|
|
<P>
|
|
|
|
<DT><CODE>exception (<VAR>except-func</VAR> [, <VAR>except-arg</VAR>])</CODE>
|
|
<DD><A NAME="IDX290"></A>
|
|
On the PowerPC running Windows NT, the <CODE>exception</CODE> attribute causes
|
|
the compiler to modify the structured exception table entry it emits for
|
|
the declared function. The string or identifier <VAR>except-func</VAR> is
|
|
placed in the third entry of the structured exception table. It
|
|
represents a function, which is called by the exception handling
|
|
mechanism if an exception occurs. If it was specified, the string or
|
|
identifier <VAR>except-arg</VAR> is placed in the fourth entry of the
|
|
structured exception table.
|
|
<P>
|
|
|
|
<DT><CODE>function_vector</CODE>
|
|
<DD><A NAME="IDX291"></A>
|
|
Use this option on the H8/300 and H8/300H to indicate that the specified
|
|
function should be called through the function vector. Calling a
|
|
function through the function vector will reduce code size, however;
|
|
the function vector has a limited size (maximum 128 entries on the H8/300
|
|
and 64 entries on the H8/300H) and shares space with the interrupt vector.
|
|
<P>
|
|
|
|
You must use GAS and GLD from GNU binutils version 2.7 or later for
|
|
this option to work correctly.
|
|
</P><P>
|
|
|
|
<DT><CODE>interrupt_handler</CODE>
|
|
<DD><A NAME="IDX292"></A>
|
|
Use this option on the H8/300 and H8/300H to indicate that the specified
|
|
function is an interrupt handler. The compiler will generate function
|
|
entry and exit sequences suitable for use in an interrupt handler when this
|
|
attribute is present.
|
|
<P>
|
|
|
|
<DT><CODE>eightbit_data</CODE>
|
|
<DD><A NAME="IDX293"></A>
|
|
Use this option on the H8/300 and H8/300H to indicate that the specified
|
|
variable should be placed into the eight bit data section.
|
|
The compiler will generate more efficient code for certain operations
|
|
on data in the eight bit data area. Note the eight bit data area is limited to
|
|
256 bytes of data.
|
|
<P>
|
|
|
|
You must use GAS and GLD from GNU binutils version 2.7 or later for
|
|
this option to work correctly.
|
|
</P><P>
|
|
|
|
<DT><CODE>tiny_data</CODE>
|
|
<DD><A NAME="IDX294"></A>
|
|
Use this option on the H8/300H to indicate that the specified
|
|
variable should be placed into the tiny data section.
|
|
The compiler will generate more efficient code for loads and stores
|
|
on data in the tiny data section. Note the tiny data area is limited to
|
|
slightly under 32kbytes of data.
|
|
<P>
|
|
|
|
<DT><CODE>interrupt</CODE>
|
|
<DD><A NAME="IDX295"></A>
|
|
Use this option on the M32R/D to indicate that the specified
|
|
function is an interrupt handler. The compiler will generate function
|
|
entry and exit sequences suitable for use in an interrupt handler when this
|
|
attribute is present.
|
|
<P>
|
|
|
|
<DT><CODE>model (<VAR>model-name</VAR>)</CODE>
|
|
<DD><A NAME="IDX296"></A>
|
|
Use this attribute on the M32R/D to set the addressability of an object,
|
|
and the code generated for a function.
|
|
The identifier <VAR>model-name</VAR> is one of <CODE>small</CODE>, <CODE>medium</CODE>,
|
|
or <CODE>large</CODE>, representing each of the code models.
|
|
<P>
|
|
|
|
Small model objects live in the lower 16MB of memory (so that their
|
|
addresses can be loaded with the <CODE>ld24</CODE> instruction), and are
|
|
callable with the <CODE>bl</CODE> instruction.
|
|
</P><P>
|
|
|
|
Medium model objects may live anywhere in the 32 bit address space (the
|
|
compiler will generate <CODE>seth/add3</CODE> instructions to load their addresses),
|
|
and are callable with the <CODE>bl</CODE> instruction.
|
|
</P><P>
|
|
|
|
Large model objects may live anywhere in the 32 bit address space (the
|
|
compiler will generate <CODE>seth/add3</CODE> instructions to load their addresses),
|
|
and may not be reachable with the <CODE>bl</CODE> instruction (the compiler will
|
|
generate the much slower <CODE>seth/add3/jl</CODE> instruction sequence).
|
|
</P><P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
You can specify multiple attributes in a declaration by separating them
|
|
by commas within the double parentheses or by immediately following an
|
|
attribute declaration with another attribute declaration.
|
|
</P><P>
|
|
|
|
<A NAME="IDX297"></A>
|
|
<A NAME="IDX298"></A>
|
|
Some people object to the <CODE>__attribute__</CODE> feature, suggesting that ANSI C's
|
|
<CODE>#pragma</CODE> should be used instead. There are two reasons for not
|
|
doing this.
|
|
</P><P>
|
|
|
|
<OL>
|
|
<LI>
|
|
It is impossible to generate <CODE>#pragma</CODE> commands from a macro.
|
|
<P>
|
|
|
|
<LI>
|
|
There is no telling what the same <CODE>#pragma</CODE> might mean in another
|
|
compiler.
|
|
</OL>
|
|
<P>
|
|
|
|
These two reasons apply to almost any application that might be proposed
|
|
for <CODE>#pragma</CODE>. It is basically a mistake to use <CODE>#pragma</CODE> for
|
|
<EM>anything</EM>.
|
|
</P><P>
|
|
|
|
<A NAME="Function Prototypes"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC85"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC84" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC86" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC86"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.24 Prototypes and Old-Style Function Definitions </H2>
|
|
<!--docid::SEC85::-->
|
|
<P>
|
|
|
|
GNU C extends ANSI C to allow a function prototype to override a later
|
|
old-style non-prototype definition. Consider the following example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>/* Use prototypes unless the compiler is old-fashioned. */
|
|
#ifdef __STDC__
|
|
#define P(x) x
|
|
#else
|
|
#define P(x) ()
|
|
#endif
|
|
|
|
/* Prototype function declaration. */
|
|
int isroot P((uid_t));
|
|
|
|
/* Old-style function definition. */
|
|
int
|
|
isroot (x) /* ??? lossage here ??? */
|
|
uid_t x;
|
|
{
|
|
return x == 0;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Suppose the type <CODE>uid_t</CODE> happens to be <CODE>short</CODE>. ANSI C does
|
|
not allow this example, because subword arguments in old-style
|
|
non-prototype definitions are promoted. Therefore in this example the
|
|
function definition's argument is really an <CODE>int</CODE>, which does not
|
|
match the prototype argument type of <CODE>short</CODE>.
|
|
</P><P>
|
|
|
|
This restriction of ANSI C makes it hard to write code that is portable
|
|
to traditional C compilers, because the programmer does not know
|
|
whether the <CODE>uid_t</CODE> type is <CODE>short</CODE>, <CODE>int</CODE>, or
|
|
<CODE>long</CODE>. Therefore, in cases like these GNU C allows a prototype
|
|
to override a later old-style definition. More precisely, in GNU C, a
|
|
function prototype argument type overrides the argument type specified
|
|
by a later old-style definition if the former type is the same as the
|
|
latter type before promotion. Thus in GNU C the above example is
|
|
equivalent to the following:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int isroot (uid_t);
|
|
|
|
int
|
|
isroot (uid_t x)
|
|
{
|
|
return x == 0;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
GNU C++ does not support old-style function definitions, so this
|
|
extension is irrelevant.
|
|
</P><P>
|
|
|
|
<A NAME="C++ Comments"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC86"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC85" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC85"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC87" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC87"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.25 C++ Style Comments </H2>
|
|
<!--docid::SEC86::-->
|
|
<P>
|
|
|
|
In GNU C, you may use C++ style comments, which start with <SAMP>`//'</SAMP> and
|
|
continue until the end of the line. Many other C implementations allow
|
|
such comments, and they are likely to be in a future C standard.
|
|
However, C++ style comments are not recognized if you specify
|
|
<SAMP>`-ansi'</SAMP> or <SAMP>`-traditional'</SAMP>, since they are incompatible
|
|
with traditional constructs like <CODE>dividend//*comment*/divisor</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="Dollar Signs"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC87"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC86" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC86"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC88" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC88"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.26 Dollar Signs in Identifier Names </H2>
|
|
<!--docid::SEC87::-->
|
|
<P>
|
|
|
|
In GNU C, you may normally use dollar signs in identifier names.
|
|
This is because many traditional C implementations allow such identifiers.
|
|
However, dollar signs in identifiers are not supported on a few target
|
|
machines, typically because the target assembler does not allow them.
|
|
</P><P>
|
|
|
|
<A NAME="Character Escapes"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC88"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC87" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC87"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC89" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC89"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.27 The Character <KBD>ESC</KBD> in Constants </H2>
|
|
<!--docid::SEC88::-->
|
|
<P>
|
|
|
|
You can use the sequence <SAMP>`\e'</SAMP> in a string or character constant to
|
|
stand for the ASCII character <KBD>ESC</KBD>.
|
|
</P><P>
|
|
|
|
<A NAME="Alignment"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC89"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC88" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC88"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC90" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC90"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.28 Inquiring on Alignment of Types or Variables </H2>
|
|
<!--docid::SEC89::-->
|
|
<P>
|
|
|
|
The keyword <CODE>__alignof__</CODE> allows you to inquire about how an object
|
|
is aligned, or the minimum alignment usually required by a type. Its
|
|
syntax is just like <CODE>sizeof</CODE>.
|
|
</P><P>
|
|
|
|
For example, if the target machine requires a <CODE>double</CODE> value to be
|
|
aligned on an 8-byte boundary, then <CODE>__alignof__ (double)</CODE> is 8.
|
|
This is true on many RISC machines. On more traditional machine
|
|
designs, <CODE>__alignof__ (double)</CODE> is 4 or even 2.
|
|
</P><P>
|
|
|
|
Some machines never actually require alignment; they allow reference to any
|
|
data type even at an odd addresses. For these machines, <CODE>__alignof__</CODE>
|
|
reports the <EM>recommended</EM> alignment of a type.
|
|
</P><P>
|
|
|
|
When the operand of <CODE>__alignof__</CODE> is an lvalue rather than a type, the
|
|
value is the largest alignment that the lvalue is known to have. It may
|
|
have this alignment as a result of its data type, or because it is part of
|
|
a structure and inherits alignment from that structure. For example, after
|
|
this declaration:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct foo { int x; char y; } foo1;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
the value of <CODE>__alignof__ (foo1.y)</CODE> is probably 2 or 4, the same as
|
|
<CODE>__alignof__ (int)</CODE>, even though the data type of <CODE>foo1.y</CODE>
|
|
does not itself demand any alignment.</P><P>
|
|
|
|
A related feature which lets you specify the alignment of an object is
|
|
<CODE>__attribute__ ((aligned (<VAR>alignment</VAR>)))</CODE>; see the following
|
|
section.
|
|
</P><P>
|
|
|
|
<A NAME="Variable Attributes"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC90"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC89" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC89"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC91" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC91"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.29 Specifying Attributes of Variables </H2>
|
|
<!--docid::SEC90::-->
|
|
<P>
|
|
|
|
The keyword <CODE>__attribute__</CODE> allows you to specify special
|
|
attributes of variables or structure fields. This keyword is followed
|
|
by an attribute specification inside double parentheses. Eight
|
|
attributes are currently defined for variables: <CODE>aligned</CODE>,
|
|
<CODE>mode</CODE>, <CODE>nocommon</CODE>, <CODE>packed</CODE>, <CODE>section</CODE>,
|
|
<CODE>transparent_union</CODE>, <CODE>unused</CODE>, and <CODE>weak</CODE>. Other
|
|
attributes are available for functions (see section <A HREF="gcc_4.html#SEC84" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84">4.23 Declaring Attributes of Functions</A>) and
|
|
for types (see section <A HREF="gcc_4.html#SEC91" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC91">4.30 Specifying Attributes of Types</A>).
|
|
</P><P>
|
|
|
|
You may also specify attributes with <SAMP>`__'</SAMP> preceding and following
|
|
each keyword. This allows you to use them in header files without
|
|
being concerned about a possible macro of the same name. For example,
|
|
you may use <CODE>__aligned__</CODE> instead of <CODE>aligned</CODE>.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX299"></A>
|
|
<DT><CODE>aligned (<VAR>alignment</VAR>)</CODE>
|
|
<DD>This attribute specifies a minimum alignment for the variable or
|
|
structure field, measured in bytes. For example, the declaration:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>int x __attribute__ ((aligned (16))) = 0;
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
causes the compiler to allocate the global variable <CODE>x</CODE> on a
|
|
16-byte boundary. On a 68040, this could be used in conjunction with
|
|
an <CODE>asm</CODE> expression to access the <CODE>move16</CODE> instruction which
|
|
requires 16-byte aligned operands.
|
|
</P><P>
|
|
|
|
You can also specify the alignment of structure fields. For example, to
|
|
create a double-word aligned <CODE>int</CODE> pair, you could write:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>struct foo { int x[2] __attribute__ ((aligned (8))); };
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
This is an alternative to creating a union with a <CODE>double</CODE> member
|
|
that forces the union to be double-word aligned.
|
|
</P><P>
|
|
|
|
It is not possible to specify the alignment of functions; the alignment
|
|
of functions is determined by the machine's requirements and cannot be
|
|
changed. You cannot specify alignment for a typedef name because such a
|
|
name is just an alias, not a distinct type.
|
|
</P><P>
|
|
|
|
As in the preceding examples, you can explicitly specify the alignment
|
|
(in bytes) that you wish the compiler to use for a given variable or
|
|
structure field. Alternatively, you can leave out the alignment factor
|
|
and just ask the compiler to align a variable or field to the maximum
|
|
useful alignment for the target machine you are compiling for. For
|
|
example, you could write:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>short array[3] __attribute__ ((aligned));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
Whenever you leave out the alignment factor in an <CODE>aligned</CODE> attribute
|
|
specification, the compiler automatically sets the alignment for the declared
|
|
variable or field to the largest alignment which is ever used for any data
|
|
type on the target machine you are compiling for. Doing this can often make
|
|
copy operations more efficient, because the compiler can use whatever
|
|
instructions copy the biggest chunks of memory when performing copies to
|
|
or from the variables or fields that you have aligned this way.
|
|
</P><P>
|
|
|
|
The <CODE>aligned</CODE> attribute can only increase the alignment; but you
|
|
can decrease it by specifying <CODE>packed</CODE> as well. See below.
|
|
</P><P>
|
|
|
|
Note that the effectiveness of <CODE>aligned</CODE> attributes may be limited
|
|
by inherent limitations in your linker. On many systems, the linker is
|
|
only able to arrange for variables to be aligned up to a certain maximum
|
|
alignment. (For some linkers, the maximum supported alignment may
|
|
be very very small.) If your linker is only able to align variables
|
|
up to a maximum of 8 byte alignment, then specifying <CODE>aligned(16)</CODE>
|
|
in an <CODE>__attribute__</CODE> will still only provide you with 8 byte
|
|
alignment. See your linker documentation for further information.
|
|
</P><P>
|
|
|
|
<DT><CODE>mode (<VAR>mode</VAR>)</CODE>
|
|
<DD><A NAME="IDX300"></A>
|
|
This attribute specifies the data type for the declaration--whichever
|
|
type corresponds to the mode <VAR>mode</VAR>. This in effect lets you
|
|
request an integer or floating point type according to its width.
|
|
<P>
|
|
|
|
You may also specify a mode of <SAMP>`byte'</SAMP> or <SAMP>`__byte__'</SAMP> to
|
|
indicate the mode corresponding to a one-byte integer, <SAMP>`word'</SAMP> or
|
|
<SAMP>`__word__'</SAMP> for the mode of a one-word integer, and <SAMP>`pointer'</SAMP>
|
|
or <SAMP>`__pointer__'</SAMP> for the mode used to represent pointers.
|
|
</P><P>
|
|
|
|
<DT><CODE>nocommon</CODE>
|
|
<DD><A NAME="IDX301"></A>
|
|
This attribute specifies requests GNU CC not to place a variable
|
|
"common" but instead to allocate space for it directly. If you
|
|
specify the <SAMP>`-fno-common'</SAMP> flag, GNU CC will do this for all
|
|
variables.
|
|
<P>
|
|
|
|
Specifying the <CODE>nocommon</CODE> attribute for a variable provides an
|
|
initialization of zeros. A variable may only be initialized in one
|
|
source file.
|
|
</P><P>
|
|
|
|
<DT><CODE>packed</CODE>
|
|
<DD><A NAME="IDX302"></A>
|
|
The <CODE>packed</CODE> attribute specifies that a variable or structure field
|
|
should have the smallest possible alignment--one byte for a variable,
|
|
and one bit for a field, unless you specify a larger value with the
|
|
<CODE>aligned</CODE> attribute.
|
|
<P>
|
|
|
|
Here is a structure in which the field <CODE>x</CODE> is packed, so that it
|
|
immediately follows <CODE>a</CODE>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct foo
|
|
{
|
|
char a;
|
|
int x[2] __attribute__ ((packed));
|
|
};
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<DT><CODE>section ("section-name")</CODE>
|
|
<DD><A NAME="IDX303"></A>
|
|
Normally, the compiler places the objects it generates in sections like
|
|
<CODE>data</CODE> and <CODE>bss</CODE>. Sometimes, however, you need additional sections,
|
|
or you need certain particular variables to appear in special sections,
|
|
for example to map to special hardware. The <CODE>section</CODE>
|
|
attribute specifies that a variable (or function) lives in a particular
|
|
section. For example, this small program uses several specific section names:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };
|
|
struct duart b __attribute__ ((section ("DUART_B"))) = { 0 };
|
|
char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };
|
|
int init_data __attribute__ ((section ("INITDATA"))) = 0;
|
|
|
|
main()
|
|
{
|
|
/* Initialize stack pointer */
|
|
init_sp (stack + sizeof (stack));
|
|
|
|
/* Initialize initialized data */
|
|
memcpy (&init_data, &data, &edata - &data);
|
|
|
|
/* Turn on the serial ports */
|
|
init_duart (&a);
|
|
init_duart (&b);
|
|
}
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
Use the <CODE>section</CODE> attribute with an <EM>initialized</EM> definition
|
|
of a <EM>global</EM> variable, as shown in the example. GNU CC issues
|
|
a warning and otherwise ignores the <CODE>section</CODE> attribute in
|
|
uninitialized variable declarations.
|
|
</P><P>
|
|
|
|
You may only use the <CODE>section</CODE> attribute with a fully initialized
|
|
global definition because of the way linkers work. The linker requires
|
|
each object be defined once, with the exception that uninitialized
|
|
variables tentatively go in the <CODE>common</CODE> (or <CODE>bss</CODE>) section
|
|
and can be multiply "defined". You can force a variable to be
|
|
initialized with the <SAMP>`-fno-common'</SAMP> flag or the <CODE>nocommon</CODE>
|
|
attribute.
|
|
</P><P>
|
|
|
|
Some file formats do not support arbitrary sections so the <CODE>section</CODE>
|
|
attribute is not available on all platforms.
|
|
If you need to map the entire contents of a module to a particular
|
|
section, consider using the facilities of the linker instead.
|
|
</P><P>
|
|
|
|
<DT><CODE>transparent_union</CODE>
|
|
<DD>This attribute, attached to a function parameter which is a union, means
|
|
that the corresponding argument may have the type of any union member,
|
|
but the argument is passed as if its type were that of the first union
|
|
member. For more details see See section <A HREF="gcc_4.html#SEC91" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC91">4.30 Specifying Attributes of Types</A>. You can also use
|
|
this attribute on a <CODE>typedef</CODE> for a union data type; then it
|
|
applies to all function parameters with that type.
|
|
<P>
|
|
|
|
<DT><CODE>unused</CODE>
|
|
<DD>This attribute, attached to a variable, means that the variable is meant
|
|
to be possibly unused. GNU CC will not produce a warning for this
|
|
variable.
|
|
<P>
|
|
|
|
<DT><CODE>weak</CODE>
|
|
<DD>The <CODE>weak</CODE> attribute is described in See section <A HREF="gcc_4.html#SEC84" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84">4.23 Declaring Attributes of Functions</A>.
|
|
<P>
|
|
|
|
<DT><CODE>model (<VAR>model-name</VAR>)</CODE>
|
|
<DD><A NAME="IDX304"></A>
|
|
Use this attribute on the M32R/D to set the addressability of an object.
|
|
The identifier <VAR>model-name</VAR> is one of <CODE>small</CODE>, <CODE>medium</CODE>,
|
|
or <CODE>large</CODE>, representing each of the code models.
|
|
<P>
|
|
|
|
Small model objects live in the lower 16MB of memory (so that their
|
|
addresses can be loaded with the <CODE>ld24</CODE> instruction).
|
|
</P><P>
|
|
|
|
Medium and large model objects may live anywhere in the 32 bit address space
|
|
(the compiler will generate <CODE>seth/add3</CODE> instructions to load their
|
|
addresses).
|
|
</P><P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
To specify multiple attributes, separate them by commas within the
|
|
double parentheses: for example, <SAMP>`__attribute__ ((aligned (16),
|
|
packed))'</SAMP>.
|
|
</P><P>
|
|
|
|
<A NAME="Type Attributes"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC91"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC90" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC90"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC92" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC92"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.30 Specifying Attributes of Types </H2>
|
|
<!--docid::SEC91::-->
|
|
<P>
|
|
|
|
The keyword <CODE>__attribute__</CODE> allows you to specify special
|
|
attributes of <CODE>struct</CODE> and <CODE>union</CODE> types when you define such
|
|
types. This keyword is followed by an attribute specification inside
|
|
double parentheses. Three attributes are currently defined for types:
|
|
<CODE>aligned</CODE>, <CODE>packed</CODE>, and <CODE>transparent_union</CODE>. Other
|
|
attributes are defined for functions (see section <A HREF="gcc_4.html#SEC84" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84">4.23 Declaring Attributes of Functions</A>) and
|
|
for variables (see section <A HREF="gcc_4.html#SEC90" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC90">4.29 Specifying Attributes of Variables</A>).
|
|
</P><P>
|
|
|
|
You may also specify any one of these attributes with <SAMP>`__'</SAMP>
|
|
preceding and following its keyword. This allows you to use these
|
|
attributes in header files without being concerned about a possible
|
|
macro of the same name. For example, you may use <CODE>__aligned__</CODE>
|
|
instead of <CODE>aligned</CODE>.
|
|
</P><P>
|
|
|
|
You may specify the <CODE>aligned</CODE> and <CODE>transparent_union</CODE>
|
|
attributes either in a <CODE>typedef</CODE> declaration or just past the
|
|
closing curly brace of a complete enum, struct or union type
|
|
<EM>definition</EM> and the <CODE>packed</CODE> attribute only past the closing
|
|
brace of a definition.
|
|
</P><P>
|
|
|
|
You may also specify attributes between the enum, struct or union
|
|
tag and the name of the type rather than after the closing brace.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX305"></A>
|
|
<DT><CODE>aligned (<VAR>alignment</VAR>)</CODE>
|
|
<DD>This attribute specifies a minimum alignment (in bytes) for variables
|
|
of the specified type. For example, the declarations:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>struct S { short f[3]; } __attribute__ ((aligned (8)));
|
|
typedef int more_aligned_int __attribute__ ((aligned (8)));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
force the compiler to insure (as far as it can) that each variable whose
|
|
type is <CODE>struct S</CODE> or <CODE>more_aligned_int</CODE> will be allocated and
|
|
aligned <EM>at least</EM> on a 8-byte boundary. On a Sparc, having all
|
|
variables of type <CODE>struct S</CODE> aligned to 8-byte boundaries allows
|
|
the compiler to use the <CODE>ldd</CODE> and <CODE>std</CODE> (doubleword load and
|
|
store) instructions when copying one variable of type <CODE>struct S</CODE> to
|
|
another, thus improving run-time efficiency.
|
|
</P><P>
|
|
|
|
Note that the alignment of any given <CODE>struct</CODE> or <CODE>union</CODE> type
|
|
is required by the ANSI C standard to be at least a perfect multiple of
|
|
the lowest common multiple of the alignments of all of the members of
|
|
the <CODE>struct</CODE> or <CODE>union</CODE> in question. This means that you <EM>can</EM>
|
|
effectively adjust the alignment of a <CODE>struct</CODE> or <CODE>union</CODE>
|
|
type by attaching an <CODE>aligned</CODE> attribute to any one of the members
|
|
of such a type, but the notation illustrated in the example above is a
|
|
more obvious, intuitive, and readable way to request the compiler to
|
|
adjust the alignment of an entire <CODE>struct</CODE> or <CODE>union</CODE> type.
|
|
</P><P>
|
|
|
|
As in the preceding example, you can explicitly specify the alignment
|
|
(in bytes) that you wish the compiler to use for a given <CODE>struct</CODE>
|
|
or <CODE>union</CODE> type. Alternatively, you can leave out the alignment factor
|
|
and just ask the compiler to align a type to the maximum
|
|
useful alignment for the target machine you are compiling for. For
|
|
example, you could write:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>struct S { short f[3]; } __attribute__ ((aligned));
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
Whenever you leave out the alignment factor in an <CODE>aligned</CODE>
|
|
attribute specification, the compiler automatically sets the alignment
|
|
for the type to the largest alignment which is ever used for any data
|
|
type on the target machine you are compiling for. Doing this can often
|
|
make copy operations more efficient, because the compiler can use
|
|
whatever instructions copy the biggest chunks of memory when performing
|
|
copies to or from the variables which have types that you have aligned
|
|
this way.
|
|
</P><P>
|
|
|
|
In the example above, if the size of each <CODE>short</CODE> is 2 bytes, then
|
|
the size of the entire <CODE>struct S</CODE> type is 6 bytes. The smallest
|
|
power of two which is greater than or equal to that is 8, so the
|
|
compiler sets the alignment for the entire <CODE>struct S</CODE> type to 8
|
|
bytes.
|
|
</P><P>
|
|
|
|
Note that although you can ask the compiler to select a time-efficient
|
|
alignment for a given type and then declare only individual stand-alone
|
|
objects of that type, the compiler's ability to select a time-efficient
|
|
alignment is primarily useful only when you plan to create arrays of
|
|
variables having the relevant (efficiently aligned) type. If you
|
|
declare or use arrays of variables of an efficiently-aligned type, then
|
|
it is likely that your program will also be doing pointer arithmetic (or
|
|
subscripting, which amounts to the same thing) on pointers to the
|
|
relevant type, and the code that the compiler generates for these
|
|
pointer arithmetic operations will often be more efficient for
|
|
efficiently-aligned types than for other types.
|
|
</P><P>
|
|
|
|
The <CODE>aligned</CODE> attribute can only increase the alignment; but you
|
|
can decrease it by specifying <CODE>packed</CODE> as well. See below.
|
|
</P><P>
|
|
|
|
Note that the effectiveness of <CODE>aligned</CODE> attributes may be limited
|
|
by inherent limitations in your linker. On many systems, the linker is
|
|
only able to arrange for variables to be aligned up to a certain maximum
|
|
alignment. (For some linkers, the maximum supported alignment may
|
|
be very very small.) If your linker is only able to align variables
|
|
up to a maximum of 8 byte alignment, then specifying <CODE>aligned(16)</CODE>
|
|
in an <CODE>__attribute__</CODE> will still only provide you with 8 byte
|
|
alignment. See your linker documentation for further information.
|
|
</P><P>
|
|
|
|
<DT><CODE>packed</CODE>
|
|
<DD>This attribute, attached to an <CODE>enum</CODE>, <CODE>struct</CODE>, or
|
|
<CODE>union</CODE> type definition, specified that the minimum required memory
|
|
be used to represent the type.
|
|
<P>
|
|
|
|
Specifying this attribute for <CODE>struct</CODE> and <CODE>union</CODE> types is
|
|
equivalent to specifying the <CODE>packed</CODE> attribute on each of the
|
|
structure or union members. Specifying the <SAMP>`-fshort-enums'</SAMP>
|
|
flag on the line is equivalent to specifying the <CODE>packed</CODE>
|
|
attribute on all <CODE>enum</CODE> definitions.
|
|
</P><P>
|
|
|
|
You may only specify this attribute after a closing curly brace on an
|
|
<CODE>enum</CODE> definition, not in a <CODE>typedef</CODE> declaration, unless that
|
|
declaration also contains the definition of the <CODE>enum</CODE>.
|
|
</P><P>
|
|
|
|
<DT><CODE>transparent_union</CODE>
|
|
<DD>This attribute, attached to a <CODE>union</CODE> type definition, indicates
|
|
that any function parameter having that union type causes calls to that
|
|
function to be treated in a special way.
|
|
<P>
|
|
|
|
First, the argument corresponding to a transparent union type can be of
|
|
any type in the union; no cast is required. Also, if the union contains
|
|
a pointer type, the corresponding argument can be a null pointer
|
|
constant or a void pointer expression; and if the union contains a void
|
|
pointer type, the corresponding argument can be any pointer expression.
|
|
If the union member type is a pointer, qualifiers like <CODE>const</CODE> on
|
|
the referenced type must be respected, just as with normal pointer
|
|
conversions.
|
|
</P><P>
|
|
|
|
Second, the argument is passed to the function using the calling
|
|
conventions of first member of the transparent union, not the calling
|
|
conventions of the union itself. All members of the union must have the
|
|
same machine representation; this is necessary for this argument passing
|
|
to work properly.
|
|
</P><P>
|
|
|
|
Transparent unions are designed for library functions that have multiple
|
|
interfaces for compatibility reasons. For example, suppose the
|
|
<CODE>wait</CODE> function must accept either a value of type <CODE>int *</CODE> to
|
|
comply with Posix, or a value of type <CODE>union wait *</CODE> to comply with
|
|
the 4.1BSD interface. If <CODE>wait</CODE>'s parameter were <CODE>void *</CODE>,
|
|
<CODE>wait</CODE> would accept both kinds of arguments, but it would also
|
|
accept any other pointer type and this would make argument type checking
|
|
less useful. Instead, <CODE><sys/wait.h></CODE> might define the interface
|
|
as follows:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>typedef union
|
|
{
|
|
int *__ip;
|
|
union wait *__up;
|
|
} wait_status_ptr_t __attribute__ ((__transparent_union__));
|
|
|
|
pid_t wait (wait_status_ptr_t);
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
This interface allows either <CODE>int *</CODE> or <CODE>union wait *</CODE>
|
|
arguments to be passed, using the <CODE>int *</CODE> calling convention.
|
|
The program can call <CODE>wait</CODE> with arguments of either type:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int w1 () { int w; return wait (&w); }
|
|
int w2 () { union wait w; return wait (&w); }
|
|
</pre></td></tr></table></P><P>
|
|
|
|
With this interface, <CODE>wait</CODE>'s implementation might look like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>pid_t wait (wait_status_ptr_t p)
|
|
{
|
|
return waitpid (-1, p.__ip, 0);
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<DT><CODE>unused</CODE>
|
|
<DD>When attached to a type (including a <CODE>union</CODE> or a <CODE>struct</CODE>),
|
|
this attribute means that variables of that type are meant to appear
|
|
possibly unused. GNU CC will not produce a warning for any variables of
|
|
that type, even if the variable appears to do nothing. This is often
|
|
the case with lock or thread classes, which are usually defined and then
|
|
not referenced, but contain constructors and destructors that have
|
|
nontrivial bookkeeping functions.
|
|
<P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
To specify multiple attributes, separate them by commas within the
|
|
double parentheses: for example, <SAMP>`__attribute__ ((aligned (16),
|
|
packed))'</SAMP>.
|
|
</P><P>
|
|
|
|
<A NAME="Inline"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC92"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC91" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC91"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC93" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.31 An Inline Function is As Fast As a Macro </H2>
|
|
<!--docid::SEC92::-->
|
|
<P>
|
|
|
|
By declaring a function <CODE>inline</CODE>, you can direct GNU CC to
|
|
integrate that function's code into the code for its callers. This
|
|
makes execution faster by eliminating the function-call overhead; in
|
|
addition, if any of the actual argument values are constant, their known
|
|
values may permit simplifications at compile time so that not all of the
|
|
inline function's code needs to be included. The effect on code size is
|
|
less predictable; object code may be larger or smaller with function
|
|
inlining, depending on the particular case. Inlining of functions is an
|
|
optimization and it really "works" only in optimizing compilation. If
|
|
you don't use <SAMP>`-O'</SAMP>, no function is really inline.
|
|
</P><P>
|
|
|
|
To declare a function inline, use the <CODE>inline</CODE> keyword in its
|
|
declaration, like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>inline int
|
|
inc (int *a)
|
|
{
|
|
(*a)++;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
(If you are writing a header file to be included in ANSI C programs, write
|
|
<CODE>__inline__</CODE> instead of <CODE>inline</CODE>. See section <A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99">4.35 Alternate Keywords</A>.)
|
|
You can also make all "simple enough" functions inline with the option
|
|
<SAMP>`-finline-functions'</SAMP>.
|
|
</P><P>
|
|
|
|
Note that certain usages in a function definition can make it unsuitable
|
|
for inline substitution. Among these usages are: use of varargs, use of
|
|
alloca, use of variable sized data types (see section <A HREF="gcc_4.html#SEC75" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC75">4.14 Arrays of Variable Length</A>),
|
|
use of computed goto (see section <A HREF="gcc_4.html#SEC64" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC64">4.3 Labels as Values</A>), use of nonlocal goto,
|
|
and nested functions (see section <A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65">4.4 Nested Functions</A>). Using <SAMP>`-Winline'</SAMP>
|
|
will warn when a function marked <CODE>inline</CODE> could not be substituted,
|
|
and will give the reason for the failure.
|
|
</P><P>
|
|
|
|
Note that in C and Objective C, unlike C++, the <CODE>inline</CODE> keyword
|
|
does not affect the linkage of the function.
|
|
</P><P>
|
|
|
|
<A NAME="IDX306"></A>
|
|
<A NAME="IDX307"></A>
|
|
<A NAME="IDX308"></A>
|
|
<A NAME="IDX309"></A>
|
|
GNU CC automatically inlines member functions defined within the class
|
|
body of C++ programs even if they are not explicitly declared
|
|
<CODE>inline</CODE>. (You can override this with <SAMP>`-fno-default-inline'</SAMP>;
|
|
see section <A HREF="gcc_2.html#SEC7" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC7">Options Controlling C++ Dialect</A>.)
|
|
</P><P>
|
|
|
|
<A NAME="IDX310"></A>
|
|
When a function is both inline and <CODE>static</CODE>, if all calls to the
|
|
function are integrated into the caller, and the function's address is
|
|
never used, then the function's own assembler code is never referenced.
|
|
In this case, GNU CC does not actually output assembler code for the
|
|
function, unless you specify the option <SAMP>`-fkeep-inline-functions'</SAMP>.
|
|
Some calls cannot be integrated for various reasons (in particular,
|
|
calls that precede the function's definition cannot be integrated, and
|
|
neither can recursive calls within the definition). If there is a
|
|
nonintegrated call, then the function is compiled to assembler code as
|
|
usual. The function must also be compiled as usual if the program
|
|
refers to its address, because that can't be inlined.
|
|
</P><P>
|
|
|
|
<A NAME="IDX311"></A>
|
|
When an inline function is not <CODE>static</CODE>, then the compiler must assume
|
|
that there may be calls from other source files; since a global symbol can
|
|
be defined only once in any program, the function must not be defined in
|
|
the other source files, so the calls therein cannot be integrated.
|
|
Therefore, a non-<CODE>static</CODE> inline function is always compiled on its
|
|
own in the usual fashion.
|
|
</P><P>
|
|
|
|
If you specify both <CODE>inline</CODE> and <CODE>extern</CODE> in the function
|
|
definition, then the definition is used only for inlining. In no case
|
|
is the function compiled on its own, not even if you refer to its
|
|
address explicitly. Such an address becomes an external reference, as
|
|
if you had only declared the function, and had not defined it.
|
|
</P><P>
|
|
|
|
This combination of <CODE>inline</CODE> and <CODE>extern</CODE> has almost the
|
|
effect of a macro. The way to use it is to put a function definition in
|
|
a header file with these keywords, and put another copy of the
|
|
definition (lacking <CODE>inline</CODE> and <CODE>extern</CODE>) in a library file.
|
|
The definition in the header file will cause most calls to the function
|
|
to be inlined. If any uses of the function remain, they will refer to
|
|
the single copy in the library.
|
|
</P><P>
|
|
|
|
GNU C does not inline any functions when not optimizing. It is not
|
|
clear whether it is better to inline or not, in this case, but we found
|
|
that a correct implementation when not optimizing was difficult. So we
|
|
did the easy thing, and turned it off.
|
|
</P><P>
|
|
|
|
<A NAME="Extended Asm"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC93"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC92" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC92"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC94" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC94"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC95" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC95"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.32 Assembler Instructions with C Expression Operands </H2>
|
|
<!--docid::SEC93::-->
|
|
<P>
|
|
|
|
In an assembler instruction using <CODE>asm</CODE>, you can specify the
|
|
operands of the instruction using C expressions. This means you need not
|
|
guess which registers or memory locations will contain the data you want
|
|
to use.
|
|
</P><P>
|
|
|
|
You must specify an assembler instruction template much like what
|
|
appears in a machine description, plus an operand constraint string for
|
|
each operand.
|
|
</P><P>
|
|
|
|
For example, here is how to use the 68881's <CODE>fsinx</CODE> instruction:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here <CODE>angle</CODE> is the C expression for the input operand while
|
|
<CODE>result</CODE> is that of the output operand. Each has <SAMP>`"f"'</SAMP> as its
|
|
operand constraint, saying that a floating point register is required.
|
|
The <SAMP>`='</SAMP> in <SAMP>`=f'</SAMP> indicates that the operand is an output; all
|
|
output operands' constraints must use <SAMP>`='</SAMP>. The constraints use the
|
|
same language used in the machine description (see section <A HREF="gcc_16.html#SEC175" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC175">16.6 Operand Constraints</A>).
|
|
</P><P>
|
|
|
|
Each operand is described by an operand-constraint string followed by
|
|
the C expression in parentheses. A colon separates the assembler
|
|
template from the first output operand and another separates the last
|
|
output operand from the first input, if any. Commas separate the
|
|
operands within each group. The total number of operands is limited to
|
|
ten or to the maximum number of operands in any instruction pattern in
|
|
the machine description, whichever is greater.
|
|
</P><P>
|
|
|
|
If there are no output operands but there are input operands, you must
|
|
place two consecutive colons surrounding the place where the output
|
|
operands would go.
|
|
</P><P>
|
|
|
|
Output operand expressions must be lvalues; the compiler can check this.
|
|
The input operands need not be lvalues. The compiler cannot check
|
|
whether the operands have data types that are reasonable for the
|
|
instruction being executed. It does not parse the assembler instruction
|
|
template and does not know what it means or even whether it is valid
|
|
assembler input. The extended <CODE>asm</CODE> feature is most often used for
|
|
machine instructions the compiler itself does not know exist. If
|
|
the output expression cannot be directly addressed (for example, it is a
|
|
bit field), your constraint must allow a register. In that case, GNU CC
|
|
will use the register as the output of the <CODE>asm</CODE>, and then store
|
|
that register into the output.
|
|
</P><P>
|
|
|
|
The ordinary output operands must be write-only; GNU CC will assume that
|
|
the values in these operands before the instruction are dead and need
|
|
not be generated. Extended asm supports input-output or read-write
|
|
operands. Use the constraint character <SAMP>`+'</SAMP> to indicate such an
|
|
operand and list it with the output operands.
|
|
</P><P>
|
|
|
|
When the constraints for the read-write operand (or the operand in which
|
|
only some of the bits are to be changed) allows a register, you may, as
|
|
an alternative, logically split its function into two separate operands,
|
|
one input operand and one write-only output operand. The connection
|
|
between them is expressed by constraints which say they need to be in
|
|
the same location when the instruction executes. You can use the same C
|
|
expression for both operands, or different expressions. For example,
|
|
here we write the (fictitious) <SAMP>`combine'</SAMP> instruction with
|
|
<CODE>bar</CODE> as its read-only source operand and <CODE>foo</CODE> as its
|
|
read-write destination:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The constraint <SAMP>`"0"'</SAMP> for operand 1 says that it must occupy the
|
|
same location as operand 0. A digit in constraint is allowed only in an
|
|
input operand and it must refer to an output operand.
|
|
</P><P>
|
|
|
|
Only a digit in the constraint can guarantee that one operand will be in
|
|
the same place as another. The mere fact that <CODE>foo</CODE> is the value
|
|
of both operands is not enough to guarantee that they will be in the
|
|
same place in the generated assembler code. The following would not
|
|
work reliably:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar));
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Various optimizations or reloading could cause operands 0 and 1 to be in
|
|
different registers; GNU CC knows no reason not to do so. For example, the
|
|
compiler might find a copy of the value of <CODE>foo</CODE> in one register and
|
|
use it for operand 1, but generate the output operand 0 in a different
|
|
register (copying it afterward to <CODE>foo</CODE>'s own address). Of course,
|
|
since the register for operand 1 is not even mentioned in the assembler
|
|
code, the result will not work, but GNU CC can't tell that.
|
|
</P><P>
|
|
|
|
Some instructions clobber specific hard registers. To describe this,
|
|
write a third colon after the input operands, followed by the names of
|
|
the clobbered hard registers (given as strings). Here is a realistic
|
|
example for the VAX:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm volatile ("movc3 %0,%1,%2"
|
|
: /* no outputs */
|
|
: "g" (from), "g" (to), "g" (count)
|
|
: "r0", "r1", "r2", "r3", "r4", "r5");
|
|
</pre></td></tr></table></P><P>
|
|
|
|
It is an error for a clobber description to overlap an input or output
|
|
operand (for example, an operand describing a register class with one
|
|
member, mentioned in the clobber list). Most notably, it is invalid to
|
|
describe that an input operand is modified, but unused as output. It has
|
|
to be specified as an input and output operand anyway. Note that if there
|
|
are only unused output operands, you will then also need to specify
|
|
<CODE>volatile</CODE> for the <CODE>asm</CODE> construct, as described below.
|
|
</P><P>
|
|
|
|
If you refer to a particular hardware register from the assembler code,
|
|
you will probably have to list the register after the third colon to
|
|
tell the compiler the register's value is modified. In some assemblers,
|
|
the register names begin with <SAMP>`%'</SAMP>; to produce one <SAMP>`%'</SAMP> in the
|
|
assembler code, you must write <SAMP>`%%'</SAMP> in the input.
|
|
</P><P>
|
|
|
|
If your assembler instruction can alter the condition code register, add
|
|
<SAMP>`cc'</SAMP> to the list of clobbered registers. GNU CC on some machines
|
|
represents the condition codes as a specific hardware register;
|
|
<SAMP>`cc'</SAMP> serves to name this register. On other machines, the
|
|
condition code is handled differently, and specifying <SAMP>`cc'</SAMP> has no
|
|
effect. But it is valid no matter what the machine.
|
|
</P><P>
|
|
|
|
If your assembler instruction modifies memory in an unpredictable
|
|
fashion, add <SAMP>`memory'</SAMP> to the list of clobbered registers. This
|
|
will cause GNU CC to not keep memory values cached in registers across
|
|
the assembler instruction.
|
|
</P><P>
|
|
|
|
You can put multiple assembler instructions together in a single
|
|
<CODE>asm</CODE> template, separated either with newlines (written as
|
|
<SAMP>`\n'</SAMP>) or with semicolons if the assembler allows such semicolons.
|
|
The GNU assembler allows semicolons and most Unix assemblers seem to do
|
|
so. The input operands are guaranteed not to use any of the clobbered
|
|
registers, and neither will the output operands' addresses, so you can
|
|
read and write the clobbered registers as many times as you like. Here
|
|
is an example of multiple instructions in a template; it assumes the
|
|
subroutine <CODE>_foo</CODE> accepts arguments in registers 9 and 10:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("movl %0,r9;movl %1,r10;call _foo"
|
|
: /* no outputs */
|
|
: "g" (from), "g" (to)
|
|
: "r9", "r10");
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Unless an output operand has the <SAMP>`&'</SAMP> constraint modifier, GNU CC
|
|
may allocate it in the same register as an unrelated input operand, on
|
|
the assumption the inputs are consumed before the outputs are produced.
|
|
This assumption may be false if the assembler code actually consists of
|
|
more than one instruction. In such a case, use <SAMP>`&'</SAMP> for each output
|
|
operand that may not overlap an input. See section <A HREF="gcc_16.html#SEC179" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC179">16.6.4 Constraint Modifier Characters</A>.
|
|
</P><P>
|
|
|
|
If you want to test the condition code produced by an assembler
|
|
instruction, you must include a branch and a label in the <CODE>asm</CODE>
|
|
construct, as follows:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("clr %0;frob %1;beq 0f;mov #1,%0;0:"
|
|
: "g" (result)
|
|
: "g" (input));
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This assumes your assembler supports local labels, as the GNU assembler
|
|
and most Unix assemblers do.
|
|
</P><P>
|
|
|
|
Speaking of labels, jumps from one <CODE>asm</CODE> to another are not
|
|
supported. The compiler's optimizers do not know about these jumps, and
|
|
therefore they cannot take account of them when deciding how to
|
|
optimize.
|
|
</P><P>
|
|
|
|
<A NAME="IDX312"></A>
|
|
Usually the most convenient way to use these <CODE>asm</CODE> instructions is to
|
|
encapsulate them in macros that look like functions. For example,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define sin(x) \
|
|
({ double __value, __arg = (x); \
|
|
asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \
|
|
__value; })
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here the variable <CODE>__arg</CODE> is used to make sure that the instruction
|
|
operates on a proper <CODE>double</CODE> value, and to accept only those
|
|
arguments <CODE>x</CODE> which can convert automatically to a <CODE>double</CODE>.
|
|
</P><P>
|
|
|
|
Another way to make sure the instruction operates on the correct data
|
|
type is to use a cast in the <CODE>asm</CODE>. This is different from using a
|
|
variable <CODE>__arg</CODE> in that it converts more different types. For
|
|
example, if the desired type were <CODE>int</CODE>, casting the argument to
|
|
<CODE>int</CODE> would accept a pointer with no complaint, while assigning the
|
|
argument to an <CODE>int</CODE> variable named <CODE>__arg</CODE> would warn about
|
|
using a pointer unless the caller explicitly casts it.
|
|
</P><P>
|
|
|
|
If an <CODE>asm</CODE> has output operands, GNU CC assumes for optimization
|
|
purposes the instruction has no side effects except to change the output
|
|
operands. This does not mean instructions with a side effect cannot be
|
|
used, but you must be careful, because the compiler may eliminate them
|
|
if the output operands aren't used, or move them out of loops, or
|
|
replace two with one if they constitute a common subexpression. Also,
|
|
if your instruction does have a side effect on a variable that otherwise
|
|
appears not to change, the old value of the variable may be reused later
|
|
if it happens to be found in a register.
|
|
</P><P>
|
|
|
|
You can prevent an <CODE>asm</CODE> instruction from being deleted, moved
|
|
significantly, or combined, by writing the keyword <CODE>volatile</CODE> after
|
|
the <CODE>asm</CODE>. For example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define get_and_set_priority(new) \
|
|
({ int __old; \
|
|
asm volatile ("get_and_set_priority %0, %1": "=g" (__old) : "g" (new)); \
|
|
__old; })
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If you write an <CODE>asm</CODE> instruction with no outputs, GNU CC will know
|
|
the instruction has side-effects and will not delete the instruction or
|
|
move it outside of loops. If the side-effects of your instruction are
|
|
not purely external, but will affect variables in your program in ways
|
|
other than reading the inputs and clobbering the specified registers or
|
|
memory, you should write the <CODE>volatile</CODE> keyword to prevent future
|
|
versions of GNU CC from moving the instruction around within a core
|
|
region.
|
|
</P><P>
|
|
|
|
An <CODE>asm</CODE> instruction without any operands or clobbers (and "old
|
|
style" <CODE>asm</CODE>) will not be deleted or moved significantly,
|
|
regardless, unless it is unreachable, the same wasy as if you had
|
|
written a <CODE>volatile</CODE> keyword.
|
|
</P><P>
|
|
|
|
Note that even a volatile <CODE>asm</CODE> instruction can be moved in ways
|
|
that appear insignificant to the compiler, such as across jump
|
|
instructions. You can't expect a sequence of volatile <CODE>asm</CODE>
|
|
instructions to remain perfectly consecutive. If you want consecutive
|
|
output, use a single <CODE>asm</CODE>.
|
|
</P><P>
|
|
|
|
It is a natural idea to look for a way to give access to the condition
|
|
code left by the assembler instruction. However, when we attempted to
|
|
implement this, we found no way to make it work reliably. The problem
|
|
is that output operands might need reloading, which would result in
|
|
additional following "store" instructions. On most machines, these
|
|
instructions would alter the condition code before there was time to
|
|
test it. This problem doesn't arise for ordinary "test" and
|
|
"compare" instructions because they don't have any output operands.
|
|
</P><P>
|
|
|
|
If you are writing a header file that should be includable in ANSI C
|
|
programs, write <CODE>__asm__</CODE> instead of <CODE>asm</CODE>. See section <A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99">4.35 Alternate Keywords</A>.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC94"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC93" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC95" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC95"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC93" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC95" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC95"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 4.32.1 i386 floating point asm operands </H3>
|
|
<!--docid::SEC94::-->
|
|
<P>
|
|
|
|
There are several rules on the usage of stack-like regs in
|
|
asm_operands insns. These rules apply only to the operands that are
|
|
stack-like regs:
|
|
</P><P>
|
|
|
|
<OL>
|
|
<LI>
|
|
Given a set of input regs that die in an asm_operands, it is
|
|
necessary to know which are implicitly popped by the asm, and
|
|
which must be explicitly popped by gcc.
|
|
<P>
|
|
|
|
An input reg that is implicitly popped by the asm must be
|
|
explicitly clobbered, unless it is constrained to match an
|
|
output operand.
|
|
</P><P>
|
|
|
|
<LI>
|
|
For any input reg that is implicitly popped by an asm, it is
|
|
necessary to know how to adjust the stack to compensate for the pop.
|
|
If any non-popped input is closer to the top of the reg-stack than
|
|
the implicitly popped reg, it would not be possible to know what the
|
|
stack looked like -- it's not clear how the rest of the stack "slides
|
|
up".
|
|
<P>
|
|
|
|
All implicitly popped input regs must be closer to the top of
|
|
the reg-stack than any input that is not implicitly popped.
|
|
</P><P>
|
|
|
|
It is possible that if an input dies in an insn, reload might
|
|
use the input reg for an output reload. Consider this example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("foo" : "=t" (a) : "f" (b));
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This asm says that input B is not popped by the asm, and that
|
|
the asm pushes a result onto the reg-stack, ie, the stack is one
|
|
deeper after the asm than it was before. But, it is possible that
|
|
reload will think that it can use the same reg for both the input and
|
|
the output, if input B dies in this insn.
|
|
</P><P>
|
|
|
|
If any input operand uses the <CODE>f</CODE> constraint, all output reg
|
|
constraints must use the <CODE>&</CODE> earlyclobber.
|
|
</P><P>
|
|
|
|
The asm above would be written as
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("foo" : "=&t" (a) : "f" (b));
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
Some operands need to be in particular places on the stack. All
|
|
output operands fall in this category -- there is no other way to
|
|
know which regs the outputs appear in unless the user indicates
|
|
this in the constraints.
|
|
<P>
|
|
|
|
Output operands must specifically indicate which reg an output
|
|
appears in after an asm. <CODE>=f</CODE> is not allowed: the operand
|
|
constraints must select a class with a single reg.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Output operands may not be "inserted" between existing stack regs.
|
|
Since no 387 opcode uses a read/write operand, all output operands
|
|
are dead before the asm_operands, and are pushed by the asm_operands.
|
|
It makes no sense to push anywhere but the top of the reg-stack.
|
|
<P>
|
|
|
|
Output operands must start at the top of the reg-stack: output
|
|
operands may not "skip" a reg.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Some asm statements may need extra stack space for internal
|
|
calculations. This can be guaranteed by clobbering stack registers
|
|
unrelated to the inputs and outputs.
|
|
<P>
|
|
|
|
</OL>
|
|
<P>
|
|
|
|
Here are a couple of reasonable asms to want to write. This asm
|
|
takes one input, which is internally popped, and produces two outputs.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp));
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This asm takes two inputs, which are popped by the <CODE>fyl2xp1</CODE> opcode,
|
|
and replaces them with one output. The user must code the <CODE>st(1)</CODE>
|
|
clobber for reg-stack.c to know that <CODE>fyl2xp1</CODE> pops both inputs.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Asm Labels"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC95"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC94" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC94"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC96" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC96"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.33 Controlling Names Used in Assembler Code </H2>
|
|
<!--docid::SEC95::-->
|
|
<P>
|
|
|
|
You can specify the name to be used in the assembler code for a C
|
|
function or variable by writing the <CODE>asm</CODE> (or <CODE>__asm__</CODE>)
|
|
keyword after the declarator as follows:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int foo asm ("myfoo") = 2;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This specifies that the name to be used for the variable <CODE>foo</CODE> in
|
|
the assembler code should be <SAMP>`myfoo'</SAMP> rather than the usual
|
|
<SAMP>`_foo'</SAMP>.
|
|
</P><P>
|
|
|
|
On systems where an underscore is normally prepended to the name of a C
|
|
function or variable, this feature allows you to define names for the
|
|
linker that do not start with an underscore.
|
|
</P><P>
|
|
|
|
You cannot use <CODE>asm</CODE> in this way in a function <EM>definition</EM>; but
|
|
you can get the same effect by writing a declaration for the function
|
|
before its definition and putting <CODE>asm</CODE> there, like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>extern func () asm ("FUNC");
|
|
|
|
func (x, y)
|
|
int x, y;
|
|
<small>...</small>
|
|
</pre></td></tr></table></P><P>
|
|
|
|
It is up to you to make sure that the assembler names you choose do not
|
|
conflict with any other assembler symbols. Also, you must not use a
|
|
register name; that would produce completely invalid assembler code. GNU
|
|
CC does not as yet have the ability to store static variables in registers.
|
|
Perhaps that will be added.
|
|
</P><P>
|
|
|
|
<A NAME="Explicit Reg Vars"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC96"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC95" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC95"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC97" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC97"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.34 Variables in Specified Registers </H2>
|
|
<!--docid::SEC96::-->
|
|
<P>
|
|
|
|
GNU C allows you to put a few global variables into specified hardware
|
|
registers. You can also specify the register in which an ordinary
|
|
register variable should be allocated.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Global register variables reserve registers throughout the program.
|
|
This may be useful in programs such as programming language
|
|
interpreters which have a couple of global variables that are accessed
|
|
very often.
|
|
<P>
|
|
|
|
<LI>
|
|
Local register variables in specific registers do not reserve the
|
|
registers. The compiler's data flow analysis is capable of determining
|
|
where the specified registers contain live values, and where they are
|
|
available for other uses. Stores into local register variables may be deleted
|
|
when they appear to be dead according to dataflow analysis. References
|
|
to local register variables may be deleted or moved or simplified.
|
|
<P>
|
|
|
|
These local variables are sometimes convenient for use with the extended
|
|
<CODE>asm</CODE> feature (see section <A HREF="gcc_4.html#SEC93" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93">4.32 Assembler Instructions with C Expression Operands</A>), if you want to write one
|
|
output of the assembler instruction directly into a particular register.
|
|
(This will work provided the register you specify fits the constraints
|
|
specified for that operand in the <CODE>asm</CODE>.)
|
|
</UL>
|
|
<P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC97" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC97">4.34.1 Defining Global Register Variables</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_4.html#SEC98" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC98">4.34.2 Specifying Registers for Local Variables</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Global Reg Vars"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC97"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC96" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC96"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC98" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC98"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC96" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC96"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 4.34.1 Defining Global Register Variables </H3>
|
|
<!--docid::SEC97::-->
|
|
<P>
|
|
|
|
You can define a global register variable in GNU C like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>register int *foo asm ("a5");
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here <CODE>a5</CODE> is the name of the register which should be used. Choose a
|
|
register which is normally saved and restored by function calls on your
|
|
machine, so that library routines will not clobber it.
|
|
</P><P>
|
|
|
|
Naturally the register name is cpu-dependent, so you would need to
|
|
conditionalize your program according to cpu type. The register
|
|
<CODE>a5</CODE> would be a good choice on a 68000 for a variable of pointer
|
|
type. On machines with register windows, be sure to choose a "global"
|
|
register that is not affected magically by the function call mechanism.
|
|
</P><P>
|
|
|
|
In addition, operating systems on one type of cpu may differ in how they
|
|
name the registers; then you would need additional conditionals. For
|
|
example, some 68000 operating systems call this register <CODE>%a5</CODE>.
|
|
</P><P>
|
|
|
|
Eventually there may be a way of asking the compiler to choose a register
|
|
automatically, but first we need to figure out how it should choose and
|
|
how to enable you to guide the choice. No solution is evident.
|
|
</P><P>
|
|
|
|
Defining a global register variable in a certain register reserves that
|
|
register entirely for this use, at least within the current compilation.
|
|
The register will not be allocated for any other purpose in the functions
|
|
in the current compilation. The register will not be saved and restored by
|
|
these functions. Stores into this register are never deleted even if they
|
|
would appear to be dead, but references may be deleted or moved or
|
|
simplified.
|
|
</P><P>
|
|
|
|
It is not safe to access the global register variables from signal
|
|
handlers, or from more than one thread of control, because the system
|
|
library routines may temporarily use the register for other things (unless
|
|
you recompile them specially for the task at hand).
|
|
</P><P>
|
|
|
|
<A NAME="IDX313"></A>
|
|
It is not safe for one function that uses a global register variable to
|
|
call another such function <CODE>foo</CODE> by way of a third function
|
|
<CODE>lose</CODE> that was compiled without knowledge of this variable (i.e. in a
|
|
different source file in which the variable wasn't declared). This is
|
|
because <CODE>lose</CODE> might save the register and put some other value there.
|
|
For example, you can't expect a global register variable to be available in
|
|
the comparison-function that you pass to <CODE>qsort</CODE>, since <CODE>qsort</CODE>
|
|
might have put something else in that register. (If you are prepared to
|
|
recompile <CODE>qsort</CODE> with the same global register variable, you can
|
|
solve this problem.)
|
|
</P><P>
|
|
|
|
If you want to recompile <CODE>qsort</CODE> or other source files which do not
|
|
actually use your global register variable, so that they will not use that
|
|
register for any other purpose, then it suffices to specify the compiler
|
|
option <SAMP>`-ffixed-<VAR>reg</VAR>'</SAMP>. You need not actually add a global
|
|
register declaration to their source code.
|
|
</P><P>
|
|
|
|
A function which can alter the value of a global register variable cannot
|
|
safely be called from a function compiled without this variable, because it
|
|
could clobber the value the caller expects to find there on return.
|
|
Therefore, the function which is the entry point into the part of the
|
|
program that uses the global register variable must explicitly save and
|
|
restore the value which belongs to its caller.
|
|
</P><P>
|
|
|
|
<A NAME="IDX314"></A>
|
|
<A NAME="IDX315"></A>
|
|
<A NAME="IDX316"></A>
|
|
<A NAME="IDX317"></A>
|
|
<A NAME="IDX318"></A>
|
|
On most machines, <CODE>longjmp</CODE> will restore to each global register
|
|
variable the value it had at the time of the <CODE>setjmp</CODE>. On some
|
|
machines, however, <CODE>longjmp</CODE> will not change the value of global
|
|
register variables. To be portable, the function that called <CODE>setjmp</CODE>
|
|
should make other arrangements to save the values of the global register
|
|
variables, and to restore them in a <CODE>longjmp</CODE>. This way, the same
|
|
thing will happen regardless of what <CODE>longjmp</CODE> does.
|
|
</P><P>
|
|
|
|
All global register variable declarations must precede all function
|
|
definitions. If such a declaration could appear after function
|
|
definitions, the declaration would be too late to prevent the register from
|
|
being used for other purposes in the preceding functions.
|
|
</P><P>
|
|
|
|
Global register variables may not have initial values, because an
|
|
executable file has no means to supply initial contents for a register.
|
|
</P><P>
|
|
|
|
On the Sparc, there are reports that g3 <small>...</small> g7 are suitable
|
|
registers, but certain library functions, such as <CODE>getwd</CODE>, as well
|
|
as the subroutines for division and remainder, modify g3 and g4. g1 and
|
|
g2 are local temporaries.
|
|
</P><P>
|
|
|
|
On the 68000, a2 <small>...</small> a5 should be suitable, as should d2 <small>...</small> d7.
|
|
Of course, it will not do to use more than a few of those.
|
|
</P><P>
|
|
|
|
<A NAME="Local Reg Vars"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC98"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC97" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC97"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC96" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC96"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 4.34.2 Specifying Registers for Local Variables </H3>
|
|
<!--docid::SEC98::-->
|
|
<P>
|
|
|
|
You can define a local register variable with a specified register
|
|
like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>register int *foo asm ("a5");
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here <CODE>a5</CODE> is the name of the register which should be used. Note
|
|
that this is the same syntax used for defining global register
|
|
variables, but for a local variable it would appear within a function.
|
|
</P><P>
|
|
|
|
Naturally the register name is cpu-dependent, but this is not a
|
|
problem, since specific registers are most often useful with explicit
|
|
assembler instructions (see section <A HREF="gcc_4.html#SEC93" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93">4.32 Assembler Instructions with C Expression Operands</A>). Both of these things
|
|
generally require that you conditionalize your program according to
|
|
cpu type.
|
|
</P><P>
|
|
|
|
In addition, operating systems on one type of cpu may differ in how they
|
|
name the registers; then you would need additional conditionals. For
|
|
example, some 68000 operating systems call this register <CODE>%a5</CODE>.
|
|
</P><P>
|
|
|
|
Defining such a register variable does not reserve the register; it
|
|
remains available for other uses in places where flow control determines
|
|
the variable's value is not live. However, these registers are made
|
|
unavailable for use in the reload pass; excessive use of this feature
|
|
leaves the compiler too few available registers to compile certain
|
|
functions.
|
|
</P><P>
|
|
|
|
This option does not guarantee that GNU CC will generate code that has
|
|
this variable in the register you specify at all times. You may not
|
|
code an explicit reference to this register in an <CODE>asm</CODE> statement
|
|
and assume it will always refer to this variable.
|
|
</P><P>
|
|
|
|
Stores into local register variables may be deleted when they appear to be dead
|
|
according to dataflow analysis. References to local register variables may
|
|
be deleted or moved or simplified.
|
|
</P><P>
|
|
|
|
<A NAME="Alternate Keywords"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC99"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC98" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC98"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC100" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC100"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.35 Alternate Keywords </H2>
|
|
<!--docid::SEC99::-->
|
|
<P>
|
|
|
|
The option <SAMP>`-traditional'</SAMP> disables certain keywords; <SAMP>`-ansi'</SAMP>
|
|
disables certain others. This causes trouble when you want to use GNU C
|
|
extensions, or ANSI C features, in a general-purpose header file that
|
|
should be usable by all programs, including ANSI C programs and traditional
|
|
ones. The keywords <CODE>asm</CODE>, <CODE>typeof</CODE> and <CODE>inline</CODE> cannot be
|
|
used since they won't work in a program compiled with <SAMP>`-ansi'</SAMP>, while
|
|
the keywords <CODE>const</CODE>, <CODE>volatile</CODE>, <CODE>signed</CODE>, <CODE>typeof</CODE>
|
|
and <CODE>inline</CODE> won't work in a program compiled with
|
|
<SAMP>`-traditional'</SAMP>.</P><P>
|
|
|
|
The way to solve these problems is to put <SAMP>`__'</SAMP> at the beginning and
|
|
end of each problematical keyword. For example, use <CODE>__asm__</CODE>
|
|
instead of <CODE>asm</CODE>, <CODE>__const__</CODE> instead of <CODE>const</CODE>, and
|
|
<CODE>__inline__</CODE> instead of <CODE>inline</CODE>.
|
|
</P><P>
|
|
|
|
Other C compilers won't accept these alternative keywords; if you want to
|
|
compile with another compiler, you can define the alternate keywords as
|
|
macros to replace them with the customary keywords. It looks like this:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#ifndef __GNUC__
|
|
#define __asm__ asm
|
|
#endif
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX319"></A>
|
|
<SAMP>`-pedantic'</SAMP> causes warnings for many GNU C extensions. You can
|
|
prevent such warnings within one expression by writing
|
|
<CODE>__extension__</CODE> before the expression. <CODE>__extension__</CODE> has no
|
|
effect aside from this.
|
|
</P><P>
|
|
|
|
<A NAME="Incomplete Enums"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC100"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC99" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC99"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC101" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC101"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.36 Incomplete <CODE>enum</CODE> Types </H2>
|
|
<!--docid::SEC100::-->
|
|
<P>
|
|
|
|
You can define an <CODE>enum</CODE> tag without specifying its possible values.
|
|
This results in an incomplete type, much like what you get if you write
|
|
<CODE>struct foo</CODE> without describing the elements. A later declaration
|
|
which does specify the possible values completes the type.
|
|
</P><P>
|
|
|
|
You can't allocate variables or storage using the type while it is
|
|
incomplete. However, you can work with pointers to that type.
|
|
</P><P>
|
|
|
|
This extension may not be very useful, but it makes the handling of
|
|
<CODE>enum</CODE> more consistent with the way <CODE>struct</CODE> and <CODE>union</CODE>
|
|
are handled.
|
|
</P><P>
|
|
|
|
This extension is not supported by GNU C++.
|
|
</P><P>
|
|
|
|
<A NAME="Function Names"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC101"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC100" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC100"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC102" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC102"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.37 Function Names as Strings </H2>
|
|
<!--docid::SEC101::-->
|
|
<P>
|
|
|
|
GNU CC predefines two string variables to be the name of the current function.
|
|
The variable <CODE>__FUNCTION__</CODE> is the name of the function as it appears
|
|
in the source. The variable <CODE>__PRETTY_FUNCTION__</CODE> is the name of
|
|
the function pretty printed in a language specific fashion.
|
|
</P><P>
|
|
|
|
These names are always the same in a C function, but in a C++ function
|
|
they may be different. For example, this program:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>extern "C" {
|
|
extern int printf (char *, ...);
|
|
}
|
|
|
|
class a {
|
|
public:
|
|
sub (int i)
|
|
{
|
|
printf ("__FUNCTION__ = %s\n", __FUNCTION__);
|
|
printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
|
|
}
|
|
};
|
|
|
|
int
|
|
main (void)
|
|
{
|
|
a ax;
|
|
ax.sub (0);
|
|
return 0;
|
|
}
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
gives this output:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>__FUNCTION__ = sub
|
|
__PRETTY_FUNCTION__ = int a::sub (int)
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
These names are not macros: they are predefined string variables.
|
|
For example, <SAMP>`#ifdef __FUNCTION__'</SAMP> does not have any special
|
|
meaning inside a function, since the preprocessor does not do anything
|
|
special with the identifier <CODE>__FUNCTION__</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="Return Address"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC102"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC101" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC101"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC103" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC103"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.38 Getting the Return or Frame Address of a Function </H2>
|
|
<!--docid::SEC102::-->
|
|
<P>
|
|
|
|
These functions may be used to get information about the callers of a
|
|
function.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX320"></A>
|
|
<DT><CODE>__builtin_return_address (<VAR>level</VAR>)</CODE>
|
|
<DD>This function returns the return address of the current function, or of
|
|
one of its callers. The <VAR>level</VAR> argument is number of frames to
|
|
scan up the call stack. A value of <CODE>0</CODE> yields the return address
|
|
of the current function, a value of <CODE>1</CODE> yields the return address
|
|
of the caller of the current function, and so forth.
|
|
<P>
|
|
|
|
The <VAR>level</VAR> argument must be a constant integer.
|
|
</P><P>
|
|
|
|
On some machines it may be impossible to determine the return address of
|
|
any function other than the current one; in such cases, or when the top
|
|
of the stack has been reached, this function will return <CODE>0</CODE>.
|
|
</P><P>
|
|
|
|
This function should only be used with a non-zero argument for debugging
|
|
purposes.
|
|
</P><P>
|
|
|
|
<A NAME="IDX321"></A>
|
|
<DT><CODE>__builtin_frame_address (<VAR>level</VAR>)</CODE>
|
|
<DD>This function is similar to <CODE>__builtin_return_address</CODE>, but it
|
|
returns the address of the function frame rather than the return address
|
|
of the function. Calling <CODE>__builtin_frame_address</CODE> with a value of
|
|
<CODE>0</CODE> yields the frame address of the current function, a value of
|
|
<CODE>1</CODE> yields the frame address of the caller of the current function,
|
|
and so forth.
|
|
<P>
|
|
|
|
The frame is the area on the stack which holds local variables and saved
|
|
registers. The frame address is normally the address of the first word
|
|
pushed on to the stack by the function. However, the exact definition
|
|
depends upon the processor and the calling convention. If the processor
|
|
has a dedicated frame pointer register, and the function has a frame,
|
|
then <CODE>__builtin_frame_address</CODE> will return the value of the frame
|
|
pointer register.
|
|
</P><P>
|
|
|
|
The caveats that apply to <CODE>__builtin_return_address</CODE> apply to this
|
|
function as well.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Other Builtins"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC103"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC102" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC102"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC104" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC104"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC65" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.39 Other built-in functions provided by GNU CC </H2>
|
|
<!--docid::SEC103::-->
|
|
<P>
|
|
|
|
GNU CC provides a large number of built-in functions other than the ones
|
|
mentioned above. Some of these are for internal use in the processing
|
|
of exceptions or variable-length argument lists and will not be
|
|
documented here because they may change from time to time; we do not
|
|
recommend general use of these functions.
|
|
</P><P>
|
|
|
|
The remaining functions are provided for optimization purposes.
|
|
</P><P>
|
|
|
|
GNU CC includes builtin versions of many of the functions in the
|
|
standard C library. These will always be treated as having the same
|
|
meaning as the C library function even if you specify the
|
|
<SAMP>`-fno-builtin'</SAMP> (see section <A HREF="gcc_2.html#SEC6" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC6">2.4 Options Controlling C Dialect</A>) option. These functions
|
|
correspond to the C library functions <CODE>alloca</CODE>, <CODE>ffs</CODE>,
|
|
<CODE>abs</CODE>, <CODE>fabsf</CODE>, <CODE>fabs</CODE>, <CODE>fabsl</CODE>, <CODE>labs</CODE>,
|
|
<CODE>memcpy</CODE>, <CODE>memcmp</CODE>, <CODE>strcmp</CODE>, <CODE>strcpy</CODE>,
|
|
<CODE>strlen</CODE>, <CODE>sqrtf</CODE>, <CODE>sqrt</CODE>, <CODE>sqrtl</CODE>, <CODE>sinf</CODE>,
|
|
<CODE>sin</CODE>, <CODE>sinl</CODE>, <CODE>cosf</CODE>, <CODE>cos</CODE>, and <CODE>cosl</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX322"></A>
|
|
You can use the builtin function <CODE>__builtin_constant_p</CODE> to
|
|
determine if a value is known to be constant at compile-time and hence
|
|
that GNU CC can perform constant-folding on expressions involving that
|
|
value. The argument of the function is the value to test. The function
|
|
returns the integer 1 if the argument is known to be a compile-time
|
|
constant and 0 if it is not known to be a compile-time constant. A
|
|
return of 0 does not indicate that the value is <EM>not</EM> a constant,
|
|
but merely that GNU CC cannot prove it is a constant with the specified
|
|
value of the <SAMP>`-O'</SAMP> option.
|
|
</P><P>
|
|
|
|
You would typically use this function in an embedded application where
|
|
memory was a critical resource. If you have some complex calculation,
|
|
you may want it to be folded if it involves constants, but need to call
|
|
a function if it does not. For example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>#define Scale_Value(X) \
|
|
(__builtin_constant_p (X) ? ((X) * SCALE + OFFSET) : Scale (X))
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
You may use this builtin function in either a macro or an inline
|
|
function. However, if you use it in an inlined function and pass an
|
|
argument of the function as the argument to the builtin, GNU CC will
|
|
never return 1 when you call the inline function with a string constant
|
|
or constructor expression (see section <A HREF="gcc_4.html#SEC80" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC80">4.19 Constructor Expressions</A>) and will not return 1
|
|
when you pass a constant numeric value to the inline function unless you
|
|
specify the <SAMP>`-O'</SAMP> option.
|
|
</P><P>
|
|
|
|
<A NAME="Deprecated Features"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC104"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC103" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC103"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC66" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC66"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC61" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC61"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 4.40 Deprecated Features </H2>
|
|
<!--docid::SEC104::-->
|
|
<P>
|
|
|
|
In the past, the GNU C++ compiler was extended to experiment with new
|
|
features, at a time when the C++ language was still evolving. Now that
|
|
the C++ standard is complete, some of those features are superceded by
|
|
superior alternatives. Using the old features might cause a warning in
|
|
some cases that the feature will be dropped in the future. In other
|
|
cases, the feature might be gone already.
|
|
</P><P>
|
|
|
|
While the list below is not exhaustive, it documents some of the options
|
|
that are now deprecated:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>-fthis-is-variable</CODE>
|
|
<DD>In early versions of C++, assignment to this could be used to implement
|
|
application-defined memory allocation. Now, allocation functions
|
|
(<SAMP>`operator new'</SAMP>) are the standard-conforming way to achieve the
|
|
same effect.
|
|
<P>
|
|
|
|
<DT><CODE>-fexternal-templates</CODE>
|
|
<DD><DT><CODE>-falt-external-templates</CODE>
|
|
<DD>These are two of the many ways for g++ to implement template
|
|
instantiation. See section <A HREF="gcc_5.html#SEC110" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC110">5.5 Where's the Template?</A>. The C++ standard clearly
|
|
defines how template definitions have to be organized across
|
|
implementation units. g++ has an implicit instantiation mechanism that
|
|
should work just fine for standard-conforming code.
|
|
<P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="C++ Extensions"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC66" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC66"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
This document was generated
|
|
by <I>GCC Administrator</I> on <I>March, 17 2001</I>
|
|
using <A HREF="tppmsgs/msgs0.htm#1" tppabs="http://www.mathematik.uni-kl.de/~obachman/Texi2html"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|