1169689Skan@c Copyright (C) 2001,2002,2003,2004 Free Software Foundation, Inc. 2169689Skan@c This is part of the GCC manual. 3169689Skan@c For copying conditions, see the file gcc.texi. 4169689Skan 5169689Skan@node C Implementation 6169689Skan@chapter C Implementation-defined behavior 7169689Skan@cindex implementation-defined behavior, C language 8169689Skan 9169689SkanA conforming implementation of ISO C is required to document its 10169689Skanchoice of behavior in each of the areas that are designated 11169689Skan``implementation defined''. The following lists all such areas, 12169689Skanalong with the section numbers from the ISO/IEC 9899:1990 and ISO/IEC 13169689Skan9899:1999 standards. Some areas are only implementation-defined in 14169689Skanone version of the standard. 15169689Skan 16169689SkanSome choices depend on the externally determined ABI for the platform 17169689Skan(including standard character encodings) which GCC follows; these are 18169689Skanlisted as ``determined by ABI'' below. @xref{Compatibility, , Binary 19169689SkanCompatibility}, and @uref{http://gcc.gnu.org/readings.html}. Some 20169689Skanchoices are documented in the preprocessor manual. 21169689Skan@xref{Implementation-defined behavior, , Implementation-defined 22169689Skanbehavior, cpp, The C Preprocessor}. Some choices are made by the 23169689Skanlibrary and operating system (or other environment when compiling for 24169689Skana freestanding environment); refer to their documentation for details. 25169689Skan 26169689Skan@menu 27169689Skan* Translation implementation:: 28169689Skan* Environment implementation:: 29169689Skan* Identifiers implementation:: 30169689Skan* Characters implementation:: 31169689Skan* Integers implementation:: 32169689Skan* Floating point implementation:: 33169689Skan* Arrays and pointers implementation:: 34169689Skan* Hints implementation:: 35169689Skan* Structures unions enumerations and bit-fields implementation:: 36169689Skan* Qualifiers implementation:: 37169689Skan* Declarators implementation:: 38169689Skan* Statements implementation:: 39169689Skan* Preprocessing directives implementation:: 40169689Skan* Library functions implementation:: 41169689Skan* Architecture implementation:: 42169689Skan* Locale-specific behavior implementation:: 43169689Skan@end menu 44169689Skan 45169689Skan@node Translation implementation 46169689Skan@section Translation 47169689Skan 48169689Skan@itemize @bullet 49169689Skan@item 50169689Skan@cite{How a diagnostic is identified (C90 3.7, C99 3.10, C90 and C99 5.1.1.3).} 51169689Skan 52169689SkanDiagnostics consist of all the output sent to stderr by GCC@. 53169689Skan 54169689Skan@item 55169689Skan@cite{Whether each nonempty sequence of white-space characters other than 56169689Skannew-line is retained or replaced by one space character in translation 57169689Skanphase 3 (C90 and C99 5.1.1.2).} 58169689Skan 59169689Skan@xref{Implementation-defined behavior, , Implementation-defined 60169689Skanbehavior, cpp, The C Preprocessor}. 61169689Skan 62169689Skan@end itemize 63169689Skan 64169689Skan@node Environment implementation 65169689Skan@section Environment 66169689Skan 67169689SkanThe behavior of most of these points are dependent on the implementation 68169689Skanof the C library, and are not defined by GCC itself. 69169689Skan 70169689Skan@itemize @bullet 71169689Skan@item 72169689Skan@cite{The mapping between physical source file multibyte characters 73169689Skanand the source character set in translation phase 1 (C90 and C99 5.1.1.2).} 74169689Skan 75169689Skan@xref{Implementation-defined behavior, , Implementation-defined 76169689Skanbehavior, cpp, The C Preprocessor}. 77169689Skan 78169689Skan@end itemize 79169689Skan 80169689Skan@node Identifiers implementation 81169689Skan@section Identifiers 82169689Skan 83169689Skan@itemize @bullet 84169689Skan@item 85169689Skan@cite{Which additional multibyte characters may appear in identifiers 86169689Skanand their correspondence to universal character names (C99 6.4.2).} 87169689Skan 88169689Skan@xref{Implementation-defined behavior, , Implementation-defined 89169689Skanbehavior, cpp, The C Preprocessor}. 90169689Skan 91169689Skan@item 92169689Skan@cite{The number of significant initial characters in an identifier 93169689Skan(C90 6.1.2, C90 and C99 5.2.4.1, C99 6.4.2).} 94169689Skan 95169689SkanFor internal names, all characters are significant. For external names, 96169689Skanthe number of significant characters are defined by the linker; for 97169689Skanalmost all targets, all characters are significant. 98169689Skan 99169689Skan@item 100169689Skan@cite{Whether case distinctions are significant in an identifier with 101169689Skanexternal linkage (C90 6.1.2).} 102169689Skan 103169689SkanThis is a property of the linker. C99 requires that case distinctions 104169689Skanare always significant in identifiers with external linkage and 105169689Skansystems without this property are not supported by GCC@. 106169689Skan 107169689Skan@end itemize 108169689Skan 109169689Skan@node Characters implementation 110169689Skan@section Characters 111169689Skan 112169689Skan@itemize @bullet 113169689Skan@item 114169689Skan@cite{The number of bits in a byte (C90 3.4, C99 3.6).} 115169689Skan 116169689SkanDetermined by ABI@. 117169689Skan 118169689Skan@item 119169689Skan@cite{The values of the members of the execution character set (C90 120169689Skanand C99 5.2.1).} 121169689Skan 122169689SkanDetermined by ABI@. 123169689Skan 124169689Skan@item 125169689Skan@cite{The unique value of the member of the execution character set produced 126169689Skanfor each of the standard alphabetic escape sequences (C90 and C99 5.2.2).} 127169689Skan 128169689SkanDetermined by ABI@. 129169689Skan 130169689Skan@item 131169689Skan@cite{The value of a @code{char} object into which has been stored any 132169689Skancharacter other than a member of the basic execution character set 133169689Skan(C90 6.1.2.5, C99 6.2.5).} 134169689Skan 135169689SkanDetermined by ABI@. 136169689Skan 137169689Skan@item 138169689Skan@cite{Which of @code{signed char} or @code{unsigned char} has the same 139169689Skanrange, representation, and behavior as ``plain'' @code{char} (C90 140169689Skan6.1.2.5, C90 6.2.1.1, C99 6.2.5, C99 6.3.1.1).} 141169689Skan 142169689Skan@opindex fsigned-char 143169689Skan@opindex funsigned-char 144169689SkanDetermined by ABI@. The options @option{-funsigned-char} and 145169689Skan@option{-fsigned-char} change the default. @xref{C Dialect Options, , 146169689SkanOptions Controlling C Dialect}. 147169689Skan 148169689Skan@item 149169689Skan@cite{The mapping of members of the source character set (in character 150169689Skanconstants and string literals) to members of the execution character 151169689Skanset (C90 6.1.3.4, C99 6.4.4.4, C90 and C99 5.1.1.2).} 152169689Skan 153169689SkanDetermined by ABI@. 154169689Skan 155169689Skan@item 156169689Skan@cite{The value of an integer character constant containing more than one 157169689Skancharacter or containing a character or escape sequence that does not map 158169689Skanto a single-byte execution character (C90 6.1.3.4, C99 6.4.4.4).} 159169689Skan 160169689Skan@xref{Implementation-defined behavior, , Implementation-defined 161169689Skanbehavior, cpp, The C Preprocessor}. 162169689Skan 163169689Skan@item 164169689Skan@cite{The value of a wide character constant containing more than one 165169689Skanmultibyte character, or containing a multibyte character or escape 166169689Skansequence not represented in the extended execution character set (C90 167169689Skan6.1.3.4, C99 6.4.4.4).} 168169689Skan 169169689Skan@xref{Implementation-defined behavior, , Implementation-defined 170169689Skanbehavior, cpp, The C Preprocessor}. 171169689Skan 172169689Skan@item 173169689Skan@cite{The current locale used to convert a wide character constant consisting 174169689Skanof a single multibyte character that maps to a member of the extended 175169689Skanexecution character set into a corresponding wide character code (C90 176169689Skan6.1.3.4, C99 6.4.4.4).} 177169689Skan 178169689Skan@xref{Implementation-defined behavior, , Implementation-defined 179169689Skanbehavior, cpp, The C Preprocessor}. 180169689Skan 181169689Skan@item 182169689Skan@cite{The current locale used to convert a wide string literal into 183169689Skancorresponding wide character codes (C90 6.1.4, C99 6.4.5).} 184169689Skan 185169689Skan@xref{Implementation-defined behavior, , Implementation-defined 186169689Skanbehavior, cpp, The C Preprocessor}. 187169689Skan 188169689Skan@item 189169689Skan@cite{The value of a string literal containing a multibyte character or escape 190169689Skansequence not represented in the execution character set (C90 6.1.4, C99 6.4.5).} 191169689Skan 192169689Skan@xref{Implementation-defined behavior, , Implementation-defined 193169689Skanbehavior, cpp, The C Preprocessor}. 194169689Skan@end itemize 195169689Skan 196169689Skan@node Integers implementation 197169689Skan@section Integers 198169689Skan 199169689Skan@itemize @bullet 200169689Skan@item 201169689Skan@cite{Any extended integer types that exist in the implementation (C99 6.2.5).} 202169689Skan 203169689SkanGCC does not support any extended integer types. 204169689Skan@c The __mode__ attribute might create types of precisions not 205169689Skan@c otherwise supported, but the syntax isn't right for use everywhere 206169689Skan@c the standard type names might be used. Predefined typedefs should 207169689Skan@c be used if any extended integer types are to be defined. The 208169689Skan@c __int128_t and __uint128_t typedefs are not extended integer types 209169689Skan@c as they are generally longer than the ABI-specified intmax_t. 210169689Skan 211169689Skan@item 212169689Skan@cite{Whether signed integer types are represented using sign and magnitude, 213169689Skantwo's complement, or one's complement, and whether the extraordinary value 214169689Skanis a trap representation or an ordinary value (C99 6.2.6.2).} 215169689Skan 216169689SkanGCC supports only two's complement integer types, and all bit patterns 217169689Skanare ordinary values. 218169689Skan 219169689Skan@item 220169689Skan@cite{The rank of any extended integer type relative to another extended 221169689Skaninteger type with the same precision (C99 6.3.1.1).} 222169689Skan 223169689SkanGCC does not support any extended integer types. 224169689Skan@c If it did, there would only be one of each precision and signedness. 225169689Skan 226169689Skan@item 227169689Skan@cite{The result of, or the signal raised by, converting an integer to a 228169689Skansigned integer type when the value cannot be represented in an object of 229169689Skanthat type (C90 6.2.1.2, C99 6.3.1.3).} 230169689Skan 231169689SkanFor conversion to a type of width @math{N}, the value is reduced 232169689Skanmodulo @math{2^N} to be within range of the type; no signal is raised. 233169689Skan 234169689Skan@item 235169689Skan@cite{The results of some bitwise operations on signed integers (C90 236169689Skan6.3, C99 6.5).} 237169689Skan 238169689SkanBitwise operators act on the representation of the value including 239169689Skanboth the sign and value bits, where the sign bit is considered 240169689Skanimmediately above the highest-value value bit. Signed @samp{>>} acts 241169689Skanon negative numbers by sign extension. 242169689Skan 243169689SkanGCC does not use the latitude given in C99 only to treat certain 244169689Skanaspects of signed @samp{<<} as undefined, but this is subject to 245169689Skanchange. 246169689Skan 247169689Skan@item 248169689Skan@cite{The sign of the remainder on integer division (C90 6.3.5).} 249169689Skan 250169689SkanGCC always follows the C99 requirement that the result of division is 251169689Skantruncated towards zero. 252169689Skan 253169689Skan@end itemize 254169689Skan 255169689Skan@node Floating point implementation 256169689Skan@section Floating point 257169689Skan 258169689Skan@itemize @bullet 259169689Skan@item 260169689Skan@cite{The accuracy of the floating-point operations and of the library 261169689Skanfunctions in @code{<math.h>} and @code{<complex.h>} that return floating-point 262169689Skanresults (C90 and C99 5.2.4.2.2).} 263169689Skan 264169689SkanThe accuracy is unknown. 265169689Skan 266169689Skan@item 267169689Skan@cite{The rounding behaviors characterized by non-standard values 268169689Skanof @code{FLT_ROUNDS} @gol 269169689Skan(C90 and C99 5.2.4.2.2).} 270169689Skan 271169689SkanGCC does not use such values. 272169689Skan 273169689Skan@item 274169689Skan@cite{The evaluation methods characterized by non-standard negative 275169689Skanvalues of @code{FLT_EVAL_METHOD} (C99 5.2.4.2.2).} 276169689Skan 277169689SkanGCC does not use such values. 278169689Skan 279169689Skan@item 280169689Skan@cite{The direction of rounding when an integer is converted to a 281169689Skanfloating-point number that cannot exactly represent the original 282169689Skanvalue (C90 6.2.1.3, C99 6.3.1.4).} 283169689Skan 284169689SkanC99 Annex F is followed. 285169689Skan 286169689Skan@item 287169689Skan@cite{The direction of rounding when a floating-point number is 288169689Skanconverted to a narrower floating-point number (C90 6.2.1.4, C99 289169689Skan6.3.1.5).} 290169689Skan 291169689SkanC99 Annex F is followed. 292169689Skan 293169689Skan@item 294169689Skan@cite{How the nearest representable value or the larger or smaller 295169689Skanrepresentable value immediately adjacent to the nearest representable 296169689Skanvalue is chosen for certain floating constants (C90 6.1.3.1, C99 297169689Skan6.4.4.2).} 298169689Skan 299169689SkanC99 Annex F is followed. 300169689Skan 301169689Skan@item 302169689Skan@cite{Whether and how floating expressions are contracted when not 303169689Skandisallowed by the @code{FP_CONTRACT} pragma (C99 6.5).} 304169689Skan 305169689SkanExpressions are currently only contracted if 306169689Skan@option{-funsafe-math-optimizations} or @option{-ffast-math} are used. 307169689SkanThis is subject to change. 308169689Skan 309169689Skan@item 310169689Skan@cite{The default state for the @code{FENV_ACCESS} pragma (C99 7.6.1).} 311169689Skan 312169689SkanThis pragma is not implemented, but the default is to ``off'' unless 313169689Skan@option{-frounding-math} is used in which case it is ``on''. 314169689Skan 315169689Skan@item 316169689Skan@cite{Additional floating-point exceptions, rounding modes, environments, 317169689Skanand classifications, and their macro names (C99 7.6, C99 7.12).} 318169689Skan 319169689SkanThis is dependent on the implementation of the C library, and is not 320169689Skandefined by GCC itself. 321169689Skan 322169689Skan@item 323169689Skan@cite{The default state for the @code{FP_CONTRACT} pragma (C99 7.12.2).} 324169689Skan 325169689SkanThis pragma is not implemented. Expressions are currently only 326169689Skancontracted if @option{-funsafe-math-optimizations} or 327169689Skan@option{-ffast-math} are used. This is subject to change. 328169689Skan 329169689Skan@item 330169689Skan@cite{Whether the ``inexact'' floating-point exception can be raised 331169689Skanwhen the rounded result actually does equal the mathematical result 332169689Skanin an IEC 60559 conformant implementation (C99 F.9).} 333169689Skan 334169689SkanThis is dependent on the implementation of the C library, and is not 335169689Skandefined by GCC itself. 336169689Skan 337169689Skan@item 338169689Skan@cite{Whether the ``underflow'' (and ``inexact'') floating-point 339169689Skanexception can be raised when a result is tiny but not inexact in an 340169689SkanIEC 60559 conformant implementation (C99 F.9).} 341169689Skan 342169689SkanThis is dependent on the implementation of the C library, and is not 343169689Skandefined by GCC itself. 344169689Skan 345169689Skan@end itemize 346169689Skan 347169689Skan@node Arrays and pointers implementation 348169689Skan@section Arrays and pointers 349169689Skan 350169689Skan@itemize @bullet 351169689Skan@item 352169689Skan@cite{The result of converting a pointer to an integer or 353169689Skanvice versa (C90 6.3.4, C99 6.3.2.3).} 354169689Skan 355169689SkanA cast from pointer to integer discards most-significant bits if the 356169689Skanpointer representation is larger than the integer type, 357169689Skansign-extends@footnote{Future versions of GCC may zero-extend, or use 358169689Skana target-defined @code{ptr_extend} pattern. Do not rely on sign extension.} 359169689Skanif the pointer representation is smaller than the integer type, otherwise 360169689Skanthe bits are unchanged. 361169689Skan@c ??? We've always claimed that pointers were unsigned entities. 362169689Skan@c Shouldn't we therefore be doing zero-extension? If so, the bug 363169689Skan@c is in convert_to_integer, where we call type_for_size and request 364169689Skan@c a signed integral type. On the other hand, it might be most useful 365169689Skan@c for the target if we extend according to POINTERS_EXTEND_UNSIGNED. 366169689Skan 367169689SkanA cast from integer to pointer discards most-significant bits if the 368169689Skanpointer representation is smaller than the integer type, extends according 369169689Skanto the signedness of the integer type if the pointer representation 370169689Skanis larger than the integer type, otherwise the bits are unchanged. 371169689Skan 372169689SkanWhen casting from pointer to integer and back again, the resulting 373169689Skanpointer must reference the same object as the original pointer, otherwise 374169689Skanthe behavior is undefined. That is, one may not use integer arithmetic to 375169689Skanavoid the undefined behavior of pointer arithmetic as proscribed in 376169689SkanC99 6.5.6/8. 377169689Skan 378169689Skan@item 379169689Skan@cite{The size of the result of subtracting two pointers to elements 380169689Skanof the same array (C90 6.3.6, C99 6.5.6).} 381169689Skan 382169689SkanThe value is as specified in the standard and the type is determined 383169689Skanby the ABI@. 384169689Skan 385169689Skan@end itemize 386169689Skan 387169689Skan@node Hints implementation 388169689Skan@section Hints 389169689Skan 390169689Skan@itemize @bullet 391169689Skan@item 392169689Skan@cite{The extent to which suggestions made by using the @code{register} 393169689Skanstorage-class specifier are effective (C90 6.5.1, C99 6.7.1).} 394169689Skan 395169689SkanThe @code{register} specifier affects code generation only in these ways: 396169689Skan 397169689Skan@itemize @bullet 398169689Skan@item 399169689SkanWhen used as part of the register variable extension, see 400169689Skan@ref{Explicit Reg Vars}. 401169689Skan 402169689Skan@item 403169689SkanWhen @option{-O0} is in use, the compiler allocates distinct stack 404169689Skanmemory for all variables that do not have the @code{register} 405169689Skanstorage-class specifier; if @code{register} is specified, the variable 406169689Skanmay have a shorter lifespan than the code would indicate and may never 407169689Skanbe placed in memory. 408169689Skan 409169689Skan@item 410169689SkanOn some rare x86 targets, @code{setjmp} doesn't save the registers in 411169689Skanall circumstances. In those cases, GCC doesn't allocate any variables 412169689Skanin registers unless they are marked @code{register}. 413169689Skan 414169689Skan@end itemize 415169689Skan 416169689Skan@item 417169689Skan@cite{The extent to which suggestions made by using the inline function 418169689Skanspecifier are effective (C99 6.7.4).} 419169689Skan 420169689SkanGCC will not inline any functions if the @option{-fno-inline} option is 421169689Skanused or if @option{-O0} is used. Otherwise, GCC may still be unable to 422169689Skaninline a function for many reasons; the @option{-Winline} option may be 423169689Skanused to determine if a function has not been inlined and why not. 424169689Skan 425169689Skan@end itemize 426169689Skan 427169689Skan@node Structures unions enumerations and bit-fields implementation 428169689Skan@section Structures, unions, enumerations, and bit-fields 429169689Skan 430169689Skan@itemize @bullet 431169689Skan@item 432169689Skan@cite{A member of a union object is accessed using a member of a 433169689Skandifferent type (C90 6.3.2.3).} 434169689Skan 435169689SkanThe relevant bytes of the representation of the object are treated as 436169689Skanan object of the type used for the access. This may be a trap 437169689Skanrepresentation. 438169689Skan 439169689Skan@item 440169689Skan@cite{Whether a ``plain'' @code{int} bit-field is treated as a 441169689Skan@code{signed int} bit-field or as an @code{unsigned int} bit-field 442169689Skan(C90 6.5.2, C90 6.5.2.1, C99 6.7.2, C99 6.7.2.1).} 443169689Skan 444169689Skan@opindex funsigned-bitfields 445169689SkanBy default it is treated as @code{signed int} but this may be changed 446169689Skanby the @option{-funsigned-bitfields} option. 447169689Skan 448169689Skan@item 449169689Skan@cite{Allowable bit-field types other than @code{_Bool}, @code{signed int}, 450169689Skanand @code{unsigned int} (C99 6.7.2.1).} 451169689Skan 452169689SkanNo other types are permitted in strictly conforming mode. 453169689Skan@c Would it be better to restrict the pedwarn for other types to C90 454169689Skan@c mode and document the other types for C99 mode? 455169689Skan 456169689Skan@item 457169689Skan@cite{Whether a bit-field can straddle a storage-unit boundary (C90 458169689Skan6.5.2.1, C99 6.7.2.1).} 459169689Skan 460169689SkanDetermined by ABI@. 461169689Skan 462169689Skan@item 463169689Skan@cite{The order of allocation of bit-fields within a unit (C90 464169689Skan6.5.2.1, C99 6.7.2.1).} 465169689Skan 466169689SkanDetermined by ABI@. 467169689Skan 468169689Skan@item 469169689Skan@cite{The alignment of non-bit-field members of structures (C90 470169689Skan6.5.2.1, C99 6.7.2.1).} 471169689Skan 472169689SkanDetermined by ABI@. 473169689Skan 474169689Skan@item 475169689Skan@cite{The integer type compatible with each enumerated type (C90 476169689Skan6.5.2.2, C99 6.7.2.2).} 477169689Skan 478169689Skan@opindex fshort-enums 479169689SkanNormally, the type is @code{unsigned int} if there are no negative 480169689Skanvalues in the enumeration, otherwise @code{int}. If 481169689Skan@option{-fshort-enums} is specified, then if there are negative values 482169689Skanit is the first of @code{signed char}, @code{short} and @code{int} 483169689Skanthat can represent all the values, otherwise it is the first of 484169689Skan@code{unsigned char}, @code{unsigned short} and @code{unsigned int} 485169689Skanthat can represent all the values. 486169689Skan@c On a few unusual targets with 64-bit int, this doesn't agree with 487169689Skan@c the code and one of the types accessed via mode attributes (which 488169689Skan@c are not currently considered extended integer types) may be used. 489169689Skan@c If these types are made extended integer types, it would still be 490169689Skan@c the case that -fshort-enums stops the implementation from 491169689Skan@c conforming to C90 on those targets. 492169689Skan 493169689SkanOn some targets, @option{-fshort-enums} is the default; this is 494169689Skandetermined by the ABI@. 495169689Skan 496169689Skan@end itemize 497169689Skan 498169689Skan@node Qualifiers implementation 499169689Skan@section Qualifiers 500169689Skan 501169689Skan@itemize @bullet 502169689Skan@item 503169689Skan@cite{What constitutes an access to an object that has volatile-qualified 504169689Skantype (C90 6.5.3, C99 6.7.3).} 505169689Skan 506169689SkanSuch an object is normally accessed by pointers and used for accessing 507169689Skanhardware. In most expressions, it is intuitively obvious what is a read 508169689Skanand what is a write. For example 509169689Skan 510169689Skan@smallexample 511169689Skanvolatile int *dst = @var{somevalue}; 512169689Skanvolatile int *src = @var{someothervalue}; 513169689Skan*dst = *src; 514169689Skan@end smallexample 515169689Skan 516169689Skan@noindent 517169689Skanwill cause a read of the volatile object pointed to by @var{src} and store the 518169689Skanvalue into the volatile object pointed to by @var{dst}. There is no 519169689Skanguarantee that these reads and writes are atomic, especially for objects 520169689Skanlarger than @code{int}. 521169689Skan 522169689SkanHowever, if the volatile storage is not being modified, and the value of 523169689Skanthe volatile storage is not used, then the situation is less obvious. 524169689SkanFor example 525169689Skan 526169689Skan@smallexample 527169689Skanvolatile int *src = @var{somevalue}; 528169689Skan*src; 529169689Skan@end smallexample 530169689Skan 531169689SkanAccording to the C standard, such an expression is an rvalue whose type 532169689Skanis the unqualified version of its original type, i.e. @code{int}. Whether 533169689SkanGCC interprets this as a read of the volatile object being pointed to or 534169689Skanonly as a request to evaluate the expression for its side-effects depends 535169689Skanon this type. 536169689Skan 537169689SkanIf it is a scalar type, or on most targets an aggregate type whose only 538169689Skanmember object is of a scalar type, or a union type whose member objects 539169689Skanare of scalar types, the expression is interpreted by GCC as a read of 540169689Skanthe volatile object; in the other cases, the expression is only evaluated 541169689Skanfor its side-effects. 542169689Skan 543169689Skan@end itemize 544169689Skan 545169689Skan@node Declarators implementation 546169689Skan@section Declarators 547169689Skan 548169689Skan@itemize @bullet 549169689Skan@item 550169689Skan@cite{The maximum number of declarators that may modify an arithmetic, 551169689Skanstructure or union type (C90 6.5.4).} 552169689Skan 553169689SkanGCC is only limited by available memory. 554169689Skan 555169689Skan@end itemize 556169689Skan 557169689Skan@node Statements implementation 558169689Skan@section Statements 559169689Skan 560169689Skan@itemize @bullet 561169689Skan@item 562169689Skan@cite{The maximum number of @code{case} values in a @code{switch} 563169689Skanstatement (C90 6.6.4.2).} 564169689Skan 565169689SkanGCC is only limited by available memory. 566169689Skan 567169689Skan@end itemize 568169689Skan 569169689Skan@node Preprocessing directives implementation 570169689Skan@section Preprocessing directives 571169689Skan 572169689Skan@xref{Implementation-defined behavior, , Implementation-defined 573169689Skanbehavior, cpp, The C Preprocessor}, for details of these aspects of 574169689Skanimplementation-defined behavior. 575169689Skan 576169689Skan@itemize @bullet 577169689Skan@item 578169689Skan@cite{How sequences in both forms of header names are mapped to headers 579169689Skanor external source file names (C90 6.1.7, C99 6.4.7).} 580169689Skan 581169689Skan@item 582169689Skan@cite{Whether the value of a character constant in a constant expression 583169689Skanthat controls conditional inclusion matches the value of the same character 584169689Skanconstant in the execution character set (C90 6.8.1, C99 6.10.1).} 585169689Skan 586169689Skan@item 587169689Skan@cite{Whether the value of a single-character character constant in a 588169689Skanconstant expression that controls conditional inclusion may have a 589169689Skannegative value (C90 6.8.1, C99 6.10.1).} 590169689Skan 591169689Skan@item 592169689Skan@cite{The places that are searched for an included @samp{<>} delimited 593169689Skanheader, and how the places are specified or the header is 594169689Skanidentified (C90 6.8.2, C99 6.10.2).} 595169689Skan 596169689Skan@item 597169689Skan@cite{How the named source file is searched for in an included @samp{""} 598169689Skandelimited header (C90 6.8.2, C99 6.10.2).} 599169689Skan 600169689Skan@item 601169689Skan@cite{The method by which preprocessing tokens (possibly resulting from 602169689Skanmacro expansion) in a @code{#include} directive are combined into a header 603169689Skanname (C90 6.8.2, C99 6.10.2).} 604169689Skan 605169689Skan@item 606169689Skan@cite{The nesting limit for @code{#include} processing (C90 6.8.2, C99 607169689Skan6.10.2).} 608169689Skan 609169689Skan@item 610169689Skan@cite{Whether the @samp{#} operator inserts a @samp{\} character before 611169689Skanthe @samp{\} character that begins a universal character name in a 612169689Skancharacter constant or string literal (C99 6.10.3.2).} 613169689Skan 614169689Skan@item 615169689Skan@cite{The behavior on each recognized non-@code{STDC #pragma} 616169689Skandirective (C90 6.8.6, C99 6.10.6).} 617169689Skan 618169689Skan@xref{Pragmas, , Pragmas, cpp, The C Preprocessor}, for details of 619169689Skanpragmas accepted by GCC on all targets. @xref{Pragmas, , Pragmas 620169689SkanAccepted by GCC}, for details of target-specific pragmas. 621169689Skan 622169689Skan@item 623169689Skan@cite{The definitions for @code{__DATE__} and @code{__TIME__} when 624169689Skanrespectively, the date and time of translation are not available (C90 625169689Skan6.8.8, C99 6.10.8).} 626169689Skan 627169689Skan@end itemize 628169689Skan 629169689Skan@node Library functions implementation 630169689Skan@section Library functions 631169689Skan 632169689SkanThe behavior of most of these points are dependent on the implementation 633169689Skanof the C library, and are not defined by GCC itself. 634169689Skan 635169689Skan@itemize @bullet 636169689Skan@item 637169689Skan@cite{The null pointer constant to which the macro @code{NULL} expands 638169689Skan(C90 7.1.6, C99 7.17).} 639169689Skan 640169689SkanIn @code{<stddef.h>}, @code{NULL} expands to @code{((void *)0)}. GCC 641169689Skandoes not provide the other headers which define @code{NULL} and some 642169689Skanlibrary implementations may use other definitions in those headers. 643169689Skan 644169689Skan@end itemize 645169689Skan 646169689Skan@node Architecture implementation 647169689Skan@section Architecture 648169689Skan 649169689Skan@itemize @bullet 650169689Skan@item 651169689Skan@cite{The values or expressions assigned to the macros specified in the 652169689Skanheaders @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>} 653169689Skan(C90 and C99 5.2.4.2, C99 7.18.2, C99 7.18.3).} 654169689Skan 655169689SkanDetermined by ABI@. 656169689Skan 657169689Skan@item 658169689Skan@cite{The number, order, and encoding of bytes in any object 659169689Skan(when not explicitly specified in this International Standard) (C99 6.2.6.1).} 660169689Skan 661169689SkanDetermined by ABI@. 662169689Skan 663169689Skan@item 664169689Skan@cite{The value of the result of the @code{sizeof} operator (C90 665169689Skan6.3.3.4, C99 6.5.3.4).} 666169689Skan 667169689SkanDetermined by ABI@. 668169689Skan 669169689Skan@end itemize 670169689Skan 671169689Skan@node Locale-specific behavior implementation 672169689Skan@section Locale-specific behavior 673169689Skan 674169689SkanThe behavior of these points are dependent on the implementation 675169689Skanof the C library, and are not defined by GCC itself. 676