676 lines
22 KiB
Plaintext
676 lines
22 KiB
Plaintext
@c Copyright (C) 2001,2002,2003,2004 Free Software Foundation, Inc.
|
|
@c This is part of the GCC manual.
|
|
@c For copying conditions, see the file gcc.texi.
|
|
|
|
@node C Implementation
|
|
@chapter C Implementation-defined behavior
|
|
@cindex implementation-defined behavior, C language
|
|
|
|
A conforming implementation of ISO C is required to document its
|
|
choice of behavior in each of the areas that are designated
|
|
``implementation defined''. The following lists all such areas,
|
|
along with the section numbers from the ISO/IEC 9899:1990 and ISO/IEC
|
|
9899:1999 standards. Some areas are only implementation-defined in
|
|
one version of the standard.
|
|
|
|
Some choices depend on the externally determined ABI for the platform
|
|
(including standard character encodings) which GCC follows; these are
|
|
listed as ``determined by ABI'' below. @xref{Compatibility, , Binary
|
|
Compatibility}, and @uref{http://gcc.gnu.org/readings.html}. Some
|
|
choices are documented in the preprocessor manual.
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}. Some choices are made by the
|
|
library and operating system (or other environment when compiling for
|
|
a freestanding environment); refer to their documentation for details.
|
|
|
|
@menu
|
|
* Translation implementation::
|
|
* Environment implementation::
|
|
* Identifiers implementation::
|
|
* Characters implementation::
|
|
* Integers implementation::
|
|
* Floating point implementation::
|
|
* Arrays and pointers implementation::
|
|
* Hints implementation::
|
|
* Structures unions enumerations and bit-fields implementation::
|
|
* Qualifiers implementation::
|
|
* Declarators implementation::
|
|
* Statements implementation::
|
|
* Preprocessing directives implementation::
|
|
* Library functions implementation::
|
|
* Architecture implementation::
|
|
* Locale-specific behavior implementation::
|
|
@end menu
|
|
|
|
@node Translation implementation
|
|
@section Translation
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@cite{How a diagnostic is identified (C90 3.7, C99 3.10, C90 and C99 5.1.1.3).}
|
|
|
|
Diagnostics consist of all the output sent to stderr by GCC@.
|
|
|
|
@item
|
|
@cite{Whether each nonempty sequence of white-space characters other than
|
|
new-line is retained or replaced by one space character in translation
|
|
phase 3 (C90 and C99 5.1.1.2).}
|
|
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}.
|
|
|
|
@end itemize
|
|
|
|
@node Environment implementation
|
|
@section Environment
|
|
|
|
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 mapping between physical source file multibyte characters
|
|
and the source character set in translation phase 1 (C90 and C99 5.1.1.2).}
|
|
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}.
|
|
|
|
@end itemize
|
|
|
|
@node Identifiers implementation
|
|
@section Identifiers
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@cite{Which additional multibyte characters may appear in identifiers
|
|
and their correspondence to universal character names (C99 6.4.2).}
|
|
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}.
|
|
|
|
@item
|
|
@cite{The number of significant initial characters in an identifier
|
|
(C90 6.1.2, C90 and C99 5.2.4.1, C99 6.4.2).}
|
|
|
|
For internal names, all characters are significant. For external names,
|
|
the number of significant characters are defined by the linker; for
|
|
almost all targets, all characters are significant.
|
|
|
|
@item
|
|
@cite{Whether case distinctions are significant in an identifier with
|
|
external linkage (C90 6.1.2).}
|
|
|
|
This is a property of the linker. C99 requires that case distinctions
|
|
are always significant in identifiers with external linkage and
|
|
systems without this property are not supported by GCC@.
|
|
|
|
@end itemize
|
|
|
|
@node Characters implementation
|
|
@section Characters
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@cite{The number of bits in a byte (C90 3.4, C99 3.6).}
|
|
|
|
Determined by ABI@.
|
|
|
|
@item
|
|
@cite{The values of the members of the execution character set (C90
|
|
and C99 5.2.1).}
|
|
|
|
Determined by ABI@.
|
|
|
|
@item
|
|
@cite{The unique value of the member of the execution character set produced
|
|
for each of the standard alphabetic escape sequences (C90 and C99 5.2.2).}
|
|
|
|
Determined by ABI@.
|
|
|
|
@item
|
|
@cite{The value of a @code{char} object into which has been stored any
|
|
character other than a member of the basic execution character set
|
|
(C90 6.1.2.5, C99 6.2.5).}
|
|
|
|
Determined by ABI@.
|
|
|
|
@item
|
|
@cite{Which of @code{signed char} or @code{unsigned char} has the same
|
|
range, representation, and behavior as ``plain'' @code{char} (C90
|
|
6.1.2.5, C90 6.2.1.1, C99 6.2.5, C99 6.3.1.1).}
|
|
|
|
@opindex fsigned-char
|
|
@opindex funsigned-char
|
|
Determined by ABI@. The options @option{-funsigned-char} and
|
|
@option{-fsigned-char} change the default. @xref{C Dialect Options, ,
|
|
Options Controlling C Dialect}.
|
|
|
|
@item
|
|
@cite{The mapping of members of the source character set (in character
|
|
constants and string literals) to members of the execution character
|
|
set (C90 6.1.3.4, C99 6.4.4.4, C90 and C99 5.1.1.2).}
|
|
|
|
Determined by ABI@.
|
|
|
|
@item
|
|
@cite{The value of an integer character constant containing more than one
|
|
character or containing a character or escape sequence that does not map
|
|
to a single-byte execution character (C90 6.1.3.4, C99 6.4.4.4).}
|
|
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}.
|
|
|
|
@item
|
|
@cite{The value of a wide character constant containing more than one
|
|
multibyte character, or containing a multibyte character or escape
|
|
sequence not represented in the extended execution character set (C90
|
|
6.1.3.4, C99 6.4.4.4).}
|
|
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}.
|
|
|
|
@item
|
|
@cite{The current locale used to convert a wide character constant consisting
|
|
of a single multibyte character that maps to a member of the extended
|
|
execution character set into a corresponding wide character code (C90
|
|
6.1.3.4, C99 6.4.4.4).}
|
|
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}.
|
|
|
|
@item
|
|
@cite{The current locale used to convert a wide string literal into
|
|
corresponding wide character codes (C90 6.1.4, C99 6.4.5).}
|
|
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}.
|
|
|
|
@item
|
|
@cite{The value of a string literal containing a multibyte character or escape
|
|
sequence not represented in the execution character set (C90 6.1.4, C99 6.4.5).}
|
|
|
|
@xref{Implementation-defined behavior, , Implementation-defined
|
|
behavior, cpp, The C Preprocessor}.
|
|
@end itemize
|
|
|
|
@node Integers implementation
|
|
@section Integers
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@cite{Any extended integer types that exist in the implementation (C99 6.2.5).}
|
|
|
|
GCC does not support any extended integer types.
|
|
@c The __mode__ attribute might create types of precisions not
|
|
@c otherwise supported, but the syntax isn't right for use everywhere
|
|
@c the standard type names might be used. Predefined typedefs should
|
|
@c be used if any extended integer types are to be defined. The
|
|
@c __int128_t and __uint128_t typedefs are not extended integer types
|
|
@c as they are generally longer than the ABI-specified intmax_t.
|
|
|
|
@item
|
|
@cite{Whether signed integer types are represented using sign and magnitude,
|
|
two's complement, or one's complement, and whether the extraordinary value
|
|
is a trap representation or an ordinary value (C99 6.2.6.2).}
|
|
|
|
GCC supports only two's complement integer types, and all bit patterns
|
|
are ordinary values.
|
|
|
|
@item
|
|
@cite{The rank of any extended integer type relative to another extended
|
|
integer type with the same precision (C99 6.3.1.1).}
|
|
|
|
GCC does not support any extended integer types.
|
|
@c If it did, there would only be one of each precision and signedness.
|
|
|
|
@item
|
|
@cite{The result of, or the signal raised by, converting an integer to a
|
|
signed integer type when the value cannot be represented in an object of
|
|
that type (C90 6.2.1.2, C99 6.3.1.3).}
|
|
|
|
For conversion to a type of width @math{N}, the value is reduced
|
|
modulo @math{2^N} to be within range of the type; no signal is raised.
|
|
|
|
@item
|
|
@cite{The results of some bitwise operations on signed integers (C90
|
|
6.3, C99 6.5).}
|
|
|
|
Bitwise operators act on the representation of the value including
|
|
both the sign and value bits, where the sign bit is considered
|
|
immediately above the highest-value value bit. Signed @samp{>>} acts
|
|
on negative numbers by sign extension.
|
|
|
|
GCC does not use the latitude given in C99 only to treat certain
|
|
aspects of signed @samp{<<} as undefined, but this is subject to
|
|
change.
|
|
|
|
@item
|
|
@cite{The sign of the remainder on integer division (C90 6.3.5).}
|
|
|
|
GCC always follows the C99 requirement that the result of division is
|
|
truncated towards zero.
|
|
|
|
@end itemize
|
|
|
|
@node Floating point implementation
|
|
@section Floating point
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@cite{The accuracy of the floating-point operations and of the library
|
|
functions in @code{<math.h>} and @code{<complex.h>} that return floating-point
|
|
results (C90 and C99 5.2.4.2.2).}
|
|
|
|
The accuracy is unknown.
|
|
|
|
@item
|
|
@cite{The rounding behaviors characterized by non-standard values
|
|
of @code{FLT_ROUNDS} @gol
|
|
(C90 and C99 5.2.4.2.2).}
|
|
|
|
GCC does not use such values.
|
|
|
|
@item
|
|
@cite{The evaluation methods characterized by non-standard negative
|
|
values of @code{FLT_EVAL_METHOD} (C99 5.2.4.2.2).}
|
|
|
|
GCC does not use such values.
|
|
|
|
@item
|
|
@cite{The direction of rounding when an integer is converted to a
|
|
floating-point number that cannot exactly represent the original
|
|
value (C90 6.2.1.3, C99 6.3.1.4).}
|
|
|
|
C99 Annex F is followed.
|
|
|
|
@item
|
|
@cite{The direction of rounding when a floating-point number is
|
|
converted to a narrower floating-point number (C90 6.2.1.4, C99
|
|
6.3.1.5).}
|
|
|
|
C99 Annex F is followed.
|
|
|
|
@item
|
|
@cite{How the nearest representable value or the larger or smaller
|
|
representable value immediately adjacent to the nearest representable
|
|
value is chosen for certain floating constants (C90 6.1.3.1, C99
|
|
6.4.4.2).}
|
|
|
|
C99 Annex F is followed.
|
|
|
|
@item
|
|
@cite{Whether and how floating expressions are contracted when not
|
|
disallowed by the @code{FP_CONTRACT} pragma (C99 6.5).}
|
|
|
|
Expressions are currently only contracted if
|
|
@option{-funsafe-math-optimizations} or @option{-ffast-math} are used.
|
|
This is subject to change.
|
|
|
|
@item
|
|
@cite{The default state for the @code{FENV_ACCESS} pragma (C99 7.6.1).}
|
|
|
|
This pragma is not implemented, but the default is to ``off'' unless
|
|
@option{-frounding-math} is used in which case it is ``on''.
|
|
|
|
@item
|
|
@cite{Additional floating-point exceptions, rounding modes, environments,
|
|
and classifications, and their macro names (C99 7.6, C99 7.12).}
|
|
|
|
This is dependent on the implementation of the C library, and is not
|
|
defined by GCC itself.
|
|
|
|
@item
|
|
@cite{The default state for the @code{FP_CONTRACT} pragma (C99 7.12.2).}
|
|
|
|
This pragma is not implemented. Expressions are currently only
|
|
contracted if @option{-funsafe-math-optimizations} or
|
|
@option{-ffast-math} are used. This is subject to change.
|
|
|
|
@item
|
|
@cite{Whether the ``inexact'' floating-point exception can be raised
|
|
when the rounded result actually does equal the mathematical result
|
|
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.
|
|
|
|
@item
|
|
@cite{Whether the ``underflow'' (and ``inexact'') floating-point
|
|
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. 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.
|