implement-c.texi

理解和实践操作系统的一本好书

exception can be raised when a result is tiny but not inexact in an
IEC 60559 conformant implementation (C99 F.9).}

This is dependent on the implementation of the C library, and is not
defined by GCC itself.

@end itemize

@node Arrays and pointers implementation
@section Arrays and pointers

@itemize @bullet
@item
@cite{The result of converting a pointer to an integer or
vice versa (C90 6.3.4, C99 6.3.2.3).}

A cast from pointer to integer discards most-significant bits if the
pointer representation is larger than the integer type,
sign-extends@footnote{Future versions of GCC may zero-extend, or use
a target-defined @code{ptr_extend} pattern.  Do not rely on sign extension.}
if the pointer representation is smaller than the integer type, otherwise
the bits are unchanged.
@c ??? We've always claimed that pointers were unsigned entities.
@c Shouldn't we therefore be doing zero-extension?  If so, the bug
@c is in convert_to_integer, where we call type_for_size and request
@c a signed integral type.  On the other hand, it might be most useful
@c for the target if we extend according to POINTERS_EXTEND_UNSIGNED.

A cast from integer to pointer discards most-significant bits if the
pointer representation is smaller than the integer type, extends according
to the signedness of the integer type if the pointer representation
is larger than the integer type, otherwise the bits are unchanged.

When casting from pointer to integer and back again, the resulting
pointer must reference the same object as the original pointer, otherwise
the behavior is undefined.  That is, one may not use integer arithmetic to
avoid the undefined behavior of pointer arithmetic as proscribed in
C99 6.5.6/8.

@item
@cite{The size of the result of subtracting two pointers to elements
of the same array (C90 6.3.6, C99 6.5.6).}

The value is as specified in the standard and the type is determined
by the ABI@.

@end itemize

@node Hints implementation
@section Hints

@itemize @bullet
@item
@cite{The extent to which suggestions made by using the @code{register}
storage-class specifier are effective (C90 6.5.1, C99 6.7.1).}

The @code{register} specifier affects code generation only in these ways:

@itemize @bullet
@item
When used as part of the register variable extension, see
@ref{Explicit Reg Vars}.

@item
When @option{-O0} is in use, the compiler allocates distinct stack
memory for all variables that do not have the @code{register}
storage-class specifier; if @code{register} is specified, the variable
may have a shorter lifespan than the code would indicate and may never
be placed in memory.

@item
On some rare x86 targets, @code{setjmp} doesn't save the registers in
all circumstances.  In those cases, GCC doesn't allocate any variables
in registers unless they are marked @code{register}.

@end itemize

@item
@cite{The extent to which suggestions made by using the inline function
specifier are effective (C99 6.7.4).}

GCC will not inline any functions if the @option{-fno-inline} option is
used or if @option{-O0} is used.  Otherwise, GCC may still be unable to
inline a function for many reasons; the @option{-Winline} option may be
used to determine if a function has not been inlined and why not.

@end itemize

@node Structures unions enumerations and bit-fields implementation
@section Structures, unions, enumerations, and bit-fields

@itemize @bullet
@item
@cite{A member of a union object is accessed using a member of a
different type (C90 6.3.2.3).}

The relevant bytes of the representation of the object are treated as
an object of the type used for the access.  @xref{Type-punning}.  This
may be a trap representation.

@item
@cite{Whether a ``plain'' @code{int} bit-field is treated as a
@code{signed int} bit-field or as an @code{unsigned int} bit-field
(C90 6.5.2, C90 6.5.2.1, C99 6.7.2, C99 6.7.2.1).}

@opindex funsigned-bitfields
By default it is treated as @code{signed int} but this may be changed
by the @option{-funsigned-bitfields} option.

@item
@cite{Allowable bit-field types other than @code{_Bool}, @code{signed int},
and @code{unsigned int} (C99 6.7.2.1).}

No other types are permitted in strictly conforming mode.
@c Would it be better to restrict the pedwarn for other types to C90
@c mode and document the other types for C99 mode?

@item
@cite{Whether a bit-field can straddle a storage-unit boundary (C90
6.5.2.1, C99 6.7.2.1).}

Determined by ABI@.

@item
@cite{The order of allocation of bit-fields within a unit (C90
6.5.2.1, C99 6.7.2.1).}

Determined by ABI@.

@item
@cite{The alignment of non-bit-field members of structures (C90
6.5.2.1, C99 6.7.2.1).}

Determined by ABI@.

@item
@cite{The integer type compatible with each enumerated type (C90
6.5.2.2, C99 6.7.2.2).}

@opindex fshort-enums
Normally, the type is @code{unsigned int} if there are no negative
values in the enumeration, otherwise @code{int}.  If
@option{-fshort-enums} is specified, then if there are negative values
it is the first of @code{signed char}, @code{short} and @code{int}
that can represent all the values, otherwise it is the first of
@code{unsigned char}, @code{unsigned short} and @code{unsigned int}
that can represent all the values.
@c On a few unusual targets with 64-bit int, this doesn't agree with
@c the code and one of the types accessed via mode attributes (which
@c are not currently considered extended integer types) may be used.
@c If these types are made extended integer types, it would still be
@c the case that -fshort-enums stops the implementation from
@c conforming to C90 on those targets.

On some targets, @option{-fshort-enums} is the default; this is
determined by the ABI@.

@end itemize

@node Qualifiers implementation
@section Qualifiers

@itemize @bullet
@item
@cite{What constitutes an access to an object that has volatile-qualified
type (C90 6.5.3, C99 6.7.3).}

Such an object is normally accessed by pointers and used for accessing
hardware.  In most expressions, it is intuitively obvious what is a read
and what is a write.  For example

@smallexample
volatile int *dst = @var{somevalue};
volatile int *src = @var{someothervalue};
*dst = *src;
@end smallexample

@noindent
will cause a read of the volatile object pointed to by @var{src} and store the
value into the volatile object pointed to by @var{dst}.  There is no
guarantee that these reads and writes are atomic, especially for objects
larger than @code{int}.

However, if the volatile storage is not being modified, and the value of
the volatile storage is not used, then the situation is less obvious.
For example

@smallexample
volatile int *src = @var{somevalue};
*src;
@end smallexample

According to the C standard, such an expression is an rvalue whose type
is the unqualified version of its original type, i.e. @code{int}.  Whether
GCC interprets this as a read of the volatile object being pointed to or
only as a request to evaluate the expression for its side-effects depends
on this type.

If it is a scalar type, or on most targets an aggregate type whose only
member object is of a scalar type, or a union type whose member objects
are of scalar types, the expression is interpreted by GCC as a read of
the volatile object; in the other cases, the expression is only evaluated
for its side-effects.

@end itemize

@node Declarators implementation
@section Declarators

@itemize @bullet
@item
@cite{The maximum number of declarators that may modify an arithmetic,
structure or union type (C90 6.5.4).}

GCC is only limited by available memory.

@end itemize

@node Statements implementation
@section Statements

@itemize @bullet
@item
@cite{The maximum number of @code{case} values in a @code{switch}
statement (C90 6.6.4.2).}

GCC is only limited by available memory.

@end itemize

@node Preprocessing directives implementation
@section Preprocessing directives

@xref{Implementation-defined behavior, , Implementation-defined
behavior, cpp, The C Preprocessor}, for details of these aspects of
implementation-defined behavior.

@itemize @bullet
@item
@cite{How sequences in both forms of header names are mapped to headers
or external source file names (C90 6.1.7, C99 6.4.7).}

@item
@cite{Whether the value of a character constant in a constant expression
that controls conditional inclusion matches the value of the same character
constant in the execution character set (C90 6.8.1, C99 6.10.1).}

@item
@cite{Whether the value of a single-character character constant in a
constant expression that controls conditional inclusion may have a
negative value (C90 6.8.1, C99 6.10.1).}

@item
@cite{The places that are searched for an included @samp{<>} delimited
header, and how the places are specified or the header is
identified (C90 6.8.2, C99 6.10.2).}

@item
@cite{How the named source file is searched for in an included @samp{""}
delimited header (C90 6.8.2, C99 6.10.2).}

@item
@cite{The method by which preprocessing tokens (possibly resulting from
macro expansion) in a @code{#include} directive are combined into a header
name (C90 6.8.2, C99 6.10.2).}

@item
@cite{The nesting limit for @code{#include} processing (C90 6.8.2, C99
6.10.2).}

@item
@cite{Whether the @samp{#} operator inserts a @samp{\} character before
the @samp{\} character that begins a universal character name in a
character constant or string literal (C99 6.10.3.2).}

@item
@cite{The behavior on each recognized non-@code{STDC #pragma}
directive (C90 6.8.6, C99 6.10.6).}

@xref{Pragmas, , Pragmas, cpp, The C Preprocessor}, for details of
pragmas accepted by GCC on all targets.  @xref{Pragmas, , Pragmas
Accepted by GCC}, for details of target-specific pragmas.

@item
@cite{The definitions for @code{__DATE__} and @code{__TIME__} when
respectively, the date and time of translation are not available (C90
6.8.8, C99 6.10.8).}

@end itemize

@node Library functions implementation
@section Library functions

The behavior of most of these points are dependent on the implementation
of the C library, and are not defined by GCC itself.

@itemize @bullet
@item
@cite{The null pointer constant to which the macro @code{NULL} expands
(C90 7.1.6, C99 7.17).}

In @code{<stddef.h>}, @code{NULL} expands to @code{((void *)0)}.  GCC
does not provide the other headers which define @code{NULL} and some
library implementations may use other definitions in those headers.

@end itemize

@node Architecture implementation
@section Architecture

@itemize @bullet
@item
@cite{The values or expressions assigned to the macros specified in the
headers @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>}
(C90 and C99 5.2.4.2, C99 7.18.2, C99 7.18.3).}

Determined by ABI@.

@item
@cite{The number, order, and encoding of bytes in any object
(when not explicitly specified in this International Standard) (C99 6.2.6.1).}

Determined by ABI@.

@item
@cite{The value of the result of the @code{sizeof} operator (C90
6.3.3.4, C99 6.5.3.4).}

Determined by ABI@.

@end itemize

@node Locale-specific behavior implementation
@section Locale-specific behavior

The behavior of these points are dependent on the implementation
of the C library, and are not defined by GCC itself.