extend.texi

早期freebsd实现

pointed to must @emph{not} be declared @code{const}.  Likewise, a
function that calls a non-@code{const} function usually must not be
@code{const}.  It does not make sense for a @code{const} function to
return @code{void}.

We recommend placing the keyword @code{const} after the function's
return type.  It makes no difference in the example above, but when the
return type is a pointer, it is the only way to make the function itself
const.  For example,

@example
const char *mincp (int);
@end example

@noindent
says that @code{mincp} returns @code{const char *}---a pointer to a
const object.  To declare @code{mincp} const, you must write this:

@example
char * const mincp (int);
@end example
  
@cindex @code{#pragma}, reason for not using
@cindex pragma, reason for not using
Some people object to this feature, suggesting that ANSI C's
@code{#pragma} should be used instead.  There are two reasons for not
doing this.

@enumerate
@item
It is impossible to generate @code{#pragma} commands from a macro.

@item
The @code{#pragma} command is just as likely as these keywords to mean
something else in another compiler.
@end enumerate

These two reasons apply to almost any application that might be proposed
for @code{#pragma}.  It is basically a mistake to use @code{#pragma} for
@emph{anything}.

The keyword @code{__attribute__} allows you to specify special
attributes when making a declaration.  This keyword is followed by an
attribute specification inside double parentheses.  One attribute,
@code{format}, is currently defined for functions.  Others are
implemented for variables and structure fields (@pxref{Function
Attributes}).

@table @code
@item format (@var{archetype}, @var{string-index}, @var{first-to-check})
@cindex @code{format} attribute
The @code{format} attribute specifies that a function takes @code{printf}
or @code{scanf} style arguments which should be type-checked against a
format string.  For example, the declaration:

@example
extern int
my_printf (void *my_object, const char *my_format, ...)
      __attribute__ ((format (printf, 2, 3)));
@end example

@noindent
causes the compiler to check the arguments in calls to @code{my_printf}
for consistency with the @code{printf} style format string argument
@code{my_format}.

The parameter @var{archetype} determines how the format string is
interpreted, and should be either @code{printf} or @code{scanf}.  The
parameter @var{string-index} specifies which argument is the format
string argument (starting from 1), while @var{first-to-check} 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}), specify the third parameter as zero.  In this case the
compiler only checks the format string for consistency.

In the example above, the format string (@code{my_format}) is the second
argument of the function @code{my_print}, and the arguments to check
start with the third argument, so the correct parameters for the format
attribute are 2 and 3.

The @code{format} 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{fprintf},
@code{sprintf}, @code{scanf}, @code{fscanf}, @code{sscanf},
@code{vprintf}, @code{vfprintf} and @code{vsprintf} whenever such
warnings are requested (using @samp{-Wformat}), so there is no need to
modify the header file @file{stdio.h}.
@end table

@node Function Prototypes
@section Prototypes and Old-Style Function Definitions
@cindex function prototype declarations
@cindex old-style function definitions
@cindex promotion of formal parameters

GNU C extends ANSI C to allow a function prototype to override a later
old-style non-prototype definition.  Consider the following example:

@example
/* @r{Use prototypes unless the compiler is old-fashioned.}  */
#if __STDC__
#define P(x) (x)
#else
#define P(x) ()
#endif

/* @r{Prototype function declaration.}  */
int isroot P((uid_t));

/* @r{Old-style function definition.}  */
int
isroot (x)   /* ??? lossage here ??? */
     uid_t x;
@{
  return x == 0;
@}
@end example

Suppose the type @code{uid_t} happens to be @code{short}.  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}, which does not
match the prototype argument type of @code{short}.

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} type is @code{short}, @code{int}, or
@code{long}.  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:

@example
int isroot (uid_t);

int
isroot (uid_t x)
@{
  return x == 0;
@}
@end example

@node Dollar Signs
@section Dollar Signs in Identifier Names
@cindex $
@cindex dollar signs in identifier names
@cindex identifier names, dollar signs in

In GNU C, you may use dollar signs in identifier names.  This is because
many traditional C implementations allow such identifiers.

On some machines, dollar signs are allowed in identifiers if you specify
@w{@samp{-traditional}}.  On a few systems they are allowed by default,
even if you do not use @w{@samp{-traditional}}.  But they are never
allowed if you specify @w{@samp{-ansi}}.

There are certain ANSI C programs (obscure, to be sure) that would
compile incorrectly if dollar signs were permitted in identifiers.  For
example:

@example
#define foo(a) #a
#define lose(b) foo (b)
#define test$
lose (test)
@end example

@node Character Escapes
@section The Character @key{ESC} in Constants

You can use the sequence @samp{\e} in a string or character constant to
stand for the ASCII character @key{ESC}.

@node Alignment
@section Inquiring on Alignment of Types or Variables
@cindex alignment
@cindex type alignment
@cindex variable alignment

The keyword @code{__alignof__} 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}.

For example, if the target machine requires a @code{double} value to be
aligned on an 8-byte boundary, then @code{__alignof__ (double)} is 8.
This is true on many RISC machines.  On more traditional machine
designs, @code{__alignof__ (double)} is 4 or even 2.

Some machines never actually require alignment; they allow reference to any
data type even at an odd addresses.  For these machines, @code{__alignof__}
reports the @emph{recommended} alignment of a type.

When the operand of @code{__alignof__} 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:

@example
struct foo @{ int x; char y; @} foo1;
@end example

@noindent
the value of @code{__alignof__ (foo1.y)} is probably 2 or 4, the same as
@code{__alignof__ (int)}, even though the data type of @code{foo1.y}
does not itself demand any alignment.@refill

A related feature which lets you specify the alignment of an object is
@code{__attribute__ ((aligned (@var{alignment})))}; see the following
section.

@node Variable Attributes
@section Specifying Attributes of Variables
@cindex attribute of variables
@cindex variable attributes

The keyword @code{__attribute__} allows you to specify special
attributes of variables or structure fields.  This keyword is followed
by an attribute specification inside double parentheses.  Four
attributes are currently defined: @code{aligned}, @code{format},
@code{mode} and @code{packed}.  @code{format} is used for functions,
and thus not documented here; see @ref{Function Attributes}.

@table @code
@cindex @code{aligned} attribute
@item aligned (@var{alignment})
This attribute specifies the alignment of the variable or structure
field, measured in bytes.  For example, the declaration:

@example
int x __attribute__ ((aligned (16))) = 0;
@end example

@noindent
causes the compiler to allocate the global variable @code{x} on a
16-byte boundary.  On a 68040, this could be used in conjunction with
an @code{asm} expression to access the @code{move16} instruction which
requires 16-byte aligned operands.

You can also specify the alignment of structure fields.  For example, to
create a double-word aligned @code{int} pair, you could write:

@example
struct foo @{ int x[2] __attribute__ ((aligned (8))); @};
@end example

@noindent
This is an alternative to creating a union with a @code{double} member
that forces the union to be double-word aligned.

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.

The linker of your operating system imposes a maximum alignment.  If the
linker aligns each object file on a four byte boundary, then it is
beyond the compiler's power to cause anything to be aligned to a larger
boundary than that.  For example, if  the linker happens to put this object
file at address 136 (eight more than a multiple of 64), then the compiler
cannot guarantee an alignment of more than 8 just by aligning variables in
the object file.

@item mode (@var{mode})
@cindex @code{mode} attribute
This attribute specifies the data type for the declaration---whichever
type corresponds to the mode @var{mode}.  This in effect lets you
request an integer or floating point type according to its width.

@item packed
@cindex @code{packed} attribute
The @code{packed} 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} attribute.
@end table

@node Inline
@section An Inline Function is As Fast As a Macro
@cindex inline functions
@cindex integrating function code
@cindex open coding
@cindex macros, inline alternative

By declaring a function @code{inline}, 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.  Inlining of functions is
an optimization and it really ``works'' only in optimizing compilation.
If you don't use @samp{-O}, no function is really inline.

To declare a function inline, use the @code{inline} keyword in its
declaration, like this:

@example
inline int
inc (int *a)
@{
  (*a)++;
@}
@end example

(If you are writing a header file to be included in ANSI C programs, write
@code{__inline__} instead of @code{inline}.  @xref{Alternate Keywords}.)

You can also make all ``simple enough'' functions inline with the option
@samp{-finline-functions}.  Note that certain usages in a function
definition can make it unsuitable for inline substitution.

@cindex inline functions, omission of
When a function is both inline and @code{static}, 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}.
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.

@cindex non-static inline function
When an inline function is not @code{static}, 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} inline function is always compiled on its
own in the usual fashion.

If you specify both @code{inline} and @code{extern} 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.

This combination of @code{inline} and @code{extern} 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} and @code{extern}) 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.

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.

@node Extended Asm
@section Assembler Instructions with C Expression Operands
@cindex extended @code{asm}
@cindex @code{asm} expressions
@cindex assembler instructions
@cindex registers

In an assembler instruction using @code{asm}, you can now specify the
operands of the instruction using C expressions.  This means no more
guessing which registers or memory locations will contain the data you want
to use.

You must specify an assembler instruction template much like what appears
in a machine description, plus an operand constraint string for each
operand.