1@c Copyright (C) 2001-2015 Free Software Foundation, Inc. 2@c This is part of the GCC manual. 3@c For copying conditions, see the file gcc.texi. 4 5@node C Implementation 6@chapter C Implementation-Defined Behavior 7@cindex implementation-defined behavior, C language 8 9A conforming implementation of ISO C is required to document its 10choice of behavior in each of the areas that are designated 11``implementation defined''. The following lists all such areas, 12along with the section numbers from the ISO/IEC 9899:1990, ISO/IEC 139899:1999 and ISO/IEC 9899:2011 standards. Some areas are only 14implementation-defined in one version of the standard. 15 16Some choices depend on the externally determined ABI for the platform 17(including standard character encodings) which GCC follows; these are 18listed as ``determined by ABI'' below. @xref{Compatibility, , Binary 19Compatibility}, and @uref{http://gcc.gnu.org/readings.html}. Some 20choices are documented in the preprocessor manual. 21@xref{Implementation-defined behavior, , Implementation-defined 22behavior, cpp, The C Preprocessor}. Some choices are made by the 23library and operating system (or other environment when compiling for 24a freestanding environment); refer to their documentation for details. 25 26@menu 27* Translation implementation:: 28* Environment implementation:: 29* Identifiers implementation:: 30* Characters implementation:: 31* Integers implementation:: 32* Floating point implementation:: 33* Arrays and pointers implementation:: 34* Hints implementation:: 35* Structures unions enumerations and bit-fields implementation:: 36* Qualifiers implementation:: 37* Declarators implementation:: 38* Statements implementation:: 39* Preprocessing directives implementation:: 40* Library functions implementation:: 41* Architecture implementation:: 42* Locale-specific behavior implementation:: 43@end menu 44 45@node Translation implementation 46@section Translation 47 48@itemize @bullet 49@item 50@cite{How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90, 51C99 and C11 5.1.1.3).} 52 53Diagnostics consist of all the output sent to stderr by GCC@. 54 55@item 56@cite{Whether each nonempty sequence of white-space characters other than 57new-line is retained or replaced by one space character in translation 58phase 3 (C90, C99 and C11 5.1.1.2).} 59 60@xref{Implementation-defined behavior, , Implementation-defined 61behavior, cpp, The C Preprocessor}. 62 63@end itemize 64 65@node Environment implementation 66@section Environment 67 68The behavior of most of these points are dependent on the implementation 69of the C library, and are not defined by GCC itself. 70 71@itemize @bullet 72@item 73@cite{The mapping between physical source file multibyte characters 74and the source character set in translation phase 1 (C90, C99 and C11 755.1.1.2).} 76 77@xref{Implementation-defined behavior, , Implementation-defined 78behavior, cpp, The C Preprocessor}. 79 80@end itemize 81 82@node Identifiers implementation 83@section Identifiers 84 85@itemize @bullet 86@item 87@cite{Which additional multibyte characters may appear in identifiers 88and their correspondence to universal character names (C99 and C11 6.4.2).} 89 90@xref{Implementation-defined behavior, , Implementation-defined 91behavior, cpp, The C Preprocessor}. 92 93@item 94@cite{The number of significant initial characters in an identifier 95(C90 6.1.2, C90, C99 and C11 5.2.4.1, C99 and C11 6.4.2).} 96 97For internal names, all characters are significant. For external names, 98the number of significant characters are defined by the linker; for 99almost all targets, all characters are significant. 100 101@item 102@cite{Whether case distinctions are significant in an identifier with 103external linkage (C90 6.1.2).} 104 105This is a property of the linker. C99 and C11 require that case distinctions 106are always significant in identifiers with external linkage and 107systems without this property are not supported by GCC@. 108 109@end itemize 110 111@node Characters implementation 112@section Characters 113 114@itemize @bullet 115@item 116@cite{The number of bits in a byte (C90 3.4, C99 and C11 3.6).} 117 118Determined by ABI@. 119 120@item 121@cite{The values of the members of the execution character set (C90, 122C99 and C11 5.2.1).} 123 124Determined by ABI@. 125 126@item 127@cite{The unique value of the member of the execution character set produced 128for each of the standard alphabetic escape sequences (C90, C99 and C11 1295.2.2).} 130 131Determined by ABI@. 132 133@item 134@cite{The value of a @code{char} object into which has been stored any 135character other than a member of the basic execution character set 136(C90 6.1.2.5, C99 and C11 6.2.5).} 137 138Determined by ABI@. 139 140@item 141@cite{Which of @code{signed char} or @code{unsigned char} has the same 142range, representation, and behavior as ``plain'' @code{char} (C90 1436.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1).} 144 145@opindex fsigned-char 146@opindex funsigned-char 147Determined by ABI@. The options @option{-funsigned-char} and 148@option{-fsigned-char} change the default. @xref{C Dialect Options, , 149Options Controlling C Dialect}. 150 151@item 152@cite{The mapping of members of the source character set (in character 153constants and string literals) to members of the execution character 154set (C90 6.1.3.4, C99 and C11 6.4.4.4, C90, C99 and C11 5.1.1.2).} 155 156Determined by ABI@. 157 158@item 159@cite{The value of an integer character constant containing more than one 160character or containing a character or escape sequence that does not map 161to a single-byte execution character (C90 6.1.3.4, C99 and C11 6.4.4.4).} 162 163@xref{Implementation-defined behavior, , Implementation-defined 164behavior, cpp, The C Preprocessor}. 165 166@item 167@cite{The value of a wide character constant containing more than one 168multibyte character or a single multibyte character that maps to 169multiple members of the extended execution character set, or 170containing a multibyte character or escape sequence not represented in 171the extended execution character set (C90 6.1.3.4, C99 and C11 1726.4.4.4).} 173 174@xref{Implementation-defined behavior, , Implementation-defined 175behavior, cpp, The C Preprocessor}. 176 177@item 178@cite{The current locale used to convert a wide character constant consisting 179of a single multibyte character that maps to a member of the extended 180execution character set into a corresponding wide character code (C90 1816.1.3.4, C99 and C11 6.4.4.4).} 182 183@xref{Implementation-defined behavior, , Implementation-defined 184behavior, cpp, The C Preprocessor}. 185 186@item 187@cite{Whether differently-prefixed wide string literal tokens can be 188concatenated and, if so, the treatment of the resulting multibyte 189character sequence (C11 6.4.5).} 190 191Such tokens may not be concatenated. 192 193@item 194@cite{The current locale used to convert a wide string literal into 195corresponding wide character codes (C90 6.1.4, C99 and C11 6.4.5).} 196 197@xref{Implementation-defined behavior, , Implementation-defined 198behavior, cpp, The C Preprocessor}. 199 200@item 201@cite{The value of a string literal containing a multibyte character or escape 202sequence not represented in the execution character set (C90 6.1.4, 203C99 and C11 6.4.5).} 204 205@xref{Implementation-defined behavior, , Implementation-defined 206behavior, cpp, The C Preprocessor}. 207 208@item 209@cite{The encoding of any of @code{wchar_t}, @code{char16_t}, and 210@code{char32_t} where the corresponding standard encoding macro 211(@code{__STDC_ISO_10646__}, @code{__STDC_UTF_16__}, or 212@code{__STDC_UTF_32__}) is not defined (C11 6.10.8.2).} 213 214@xref{Implementation-defined behavior, , Implementation-defined 215behavior, cpp, The C Preprocessor}. @code{char16_t} and 216@code{char32_t} literals are always encoded in UTF-16 and UTF-32 217respectively. 218 219@end itemize 220 221@node Integers implementation 222@section Integers 223 224@itemize @bullet 225@item 226@cite{Any extended integer types that exist in the implementation (C99 227and C11 6.2.5).} 228 229GCC does not support any extended integer types. 230@c The __mode__ attribute might create types of precisions not 231@c otherwise supported, but the syntax isn't right for use everywhere 232@c the standard type names might be used. Predefined typedefs should 233@c be used if any extended integer types are to be defined. The 234@c __int128_t and __uint128_t typedefs are not extended integer types 235@c as they are generally longer than the ABI-specified intmax_t. 236 237@item 238@cite{Whether signed integer types are represented using sign and magnitude, 239two's complement, or one's complement, and whether the extraordinary value 240is a trap representation or an ordinary value (C99 and C11 6.2.6.2).} 241 242GCC supports only two's complement integer types, and all bit patterns 243are ordinary values. 244 245@item 246@cite{The rank of any extended integer type relative to another extended 247integer type with the same precision (C99 and C11 6.3.1.1).} 248 249GCC does not support any extended integer types. 250@c If it did, there would only be one of each precision and signedness. 251 252@item 253@cite{The result of, or the signal raised by, converting an integer to a 254signed integer type when the value cannot be represented in an object of 255that type (C90 6.2.1.2, C99 and C11 6.3.1.3).} 256 257For conversion to a type of width @math{N}, the value is reduced 258modulo @math{2^N} to be within range of the type; no signal is raised. 259 260@item 261@cite{The results of some bitwise operations on signed integers (C90 2626.3, C99 and C11 6.5).} 263 264Bitwise operators act on the representation of the value including 265both the sign and value bits, where the sign bit is considered 266immediately above the highest-value value bit. Signed @samp{>>} acts 267on negative numbers by sign extension. 268 269GCC does not use the latitude given in C99 and C11 only to treat certain 270aspects of signed @samp{<<} as undefined, but this is subject to 271change. 272 273@item 274@cite{The sign of the remainder on integer division (C90 6.3.5).} 275 276GCC always follows the C99 and C11 requirement that the result of division is 277truncated towards zero. 278 279@end itemize 280 281@node Floating point implementation 282@section Floating Point 283 284@itemize @bullet 285@item 286@cite{The accuracy of the floating-point operations and of the library 287functions in @code{<math.h>} and @code{<complex.h>} that return floating-point 288results (C90, C99 and C11 5.2.4.2.2).} 289 290The accuracy is unknown. 291 292@item 293@cite{The rounding behaviors characterized by non-standard values 294of @code{FLT_ROUNDS} @gol 295(C90, C99 and C11 5.2.4.2.2).} 296 297GCC does not use such values. 298 299@item 300@cite{The evaluation methods characterized by non-standard negative 301values of @code{FLT_EVAL_METHOD} (C99 and C11 5.2.4.2.2).} 302 303GCC does not use such values. 304 305@item 306@cite{The direction of rounding when an integer is converted to a 307floating-point number that cannot exactly represent the original 308value (C90 6.2.1.3, C99 and C11 6.3.1.4).} 309 310C99 Annex F is followed. 311 312@item 313@cite{The direction of rounding when a floating-point number is 314converted to a narrower floating-point number (C90 6.2.1.4, C99 and C11 3156.3.1.5).} 316 317C99 Annex F is followed. 318 319@item 320@cite{How the nearest representable value or the larger or smaller 321representable value immediately adjacent to the nearest representable 322value is chosen for certain floating constants (C90 6.1.3.1, C99 and C11 3236.4.4.2).} 324 325C99 Annex F is followed. 326 327@item 328@cite{Whether and how floating expressions are contracted when not 329disallowed by the @code{FP_CONTRACT} pragma (C99 and C11 6.5).} 330 331Expressions are currently only contracted if @option{-ffp-contract=fast}, 332@option{-funsafe-math-optimizations} or @option{-ffast-math} are used. 333This is subject to change. 334 335@item 336@cite{The default state for the @code{FENV_ACCESS} pragma (C99 and C11 3377.6.1).} 338 339This pragma is not implemented, but the default is to ``off'' unless 340@option{-frounding-math} is used in which case it is ``on''. 341 342@item 343@cite{Additional floating-point exceptions, rounding modes, environments, 344and classifications, and their macro names (C99 and C11 7.6, C99 and 345C11 7.12).} 346 347This is dependent on the implementation of the C library, and is not 348defined by GCC itself. 349 350@item 351@cite{The default state for the @code{FP_CONTRACT} pragma (C99 and C11 3527.12.2).} 353 354This pragma is not implemented. Expressions are currently only 355contracted if @option{-ffp-contract=fast}, 356@option{-funsafe-math-optimizations} or @option{-ffast-math} are used. 357This is subject to change. 358 359@item 360@cite{Whether the ``inexact'' floating-point exception can be raised 361when the rounded result actually does equal the mathematical result 362in an IEC 60559 conformant implementation (C99 F.9).} 363 364This is dependent on the implementation of the C library, and is not 365defined by GCC itself. 366 367@item 368@cite{Whether the ``underflow'' (and ``inexact'') floating-point 369exception can be raised when a result is tiny but not inexact in an 370IEC 60559 conformant implementation (C99 F.9).} 371 372This is dependent on the implementation of the C library, and is not 373defined by GCC itself. 374 375@end itemize 376 377@node Arrays and pointers implementation 378@section Arrays and Pointers 379 380@itemize @bullet 381@item 382@cite{The result of converting a pointer to an integer or 383vice versa (C90 6.3.4, C99 and C11 6.3.2.3).} 384 385A cast from pointer to integer discards most-significant bits if the 386pointer representation is larger than the integer type, 387sign-extends@footnote{Future versions of GCC may zero-extend, or use 388a target-defined @code{ptr_extend} pattern. Do not rely on sign extension.} 389if the pointer representation is smaller than the integer type, otherwise 390the bits are unchanged. 391@c ??? We've always claimed that pointers were unsigned entities. 392@c Shouldn't we therefore be doing zero-extension? If so, the bug 393@c is in convert_to_integer, where we call type_for_size and request 394@c a signed integral type. On the other hand, it might be most useful 395@c for the target if we extend according to POINTERS_EXTEND_UNSIGNED. 396 397A cast from integer to pointer discards most-significant bits if the 398pointer representation is smaller than the integer type, extends according 399to the signedness of the integer type if the pointer representation 400is larger than the integer type, otherwise the bits are unchanged. 401 402When casting from pointer to integer and back again, the resulting 403pointer must reference the same object as the original pointer, otherwise 404the behavior is undefined. That is, one may not use integer arithmetic to 405avoid the undefined behavior of pointer arithmetic as proscribed in 406C99 and C11 6.5.6/8. 407 408@item 409@cite{The size of the result of subtracting two pointers to elements 410of the same array (C90 6.3.6, C99 and C11 6.5.6).} 411 412The value is as specified in the standard and the type is determined 413by the ABI@. 414 415@end itemize 416 417@node Hints implementation 418@section Hints 419 420@itemize @bullet 421@item 422@cite{The extent to which suggestions made by using the @code{register} 423storage-class specifier are effective (C90 6.5.1, C99 and C11 6.7.1).} 424 425The @code{register} specifier affects code generation only in these ways: 426 427@itemize @bullet 428@item 429When used as part of the register variable extension, see 430@ref{Explicit Reg Vars}. 431 432@item 433When @option{-O0} is in use, the compiler allocates distinct stack 434memory for all variables that do not have the @code{register} 435storage-class specifier; if @code{register} is specified, the variable 436may have a shorter lifespan than the code would indicate and may never 437be placed in memory. 438 439@item 440On some rare x86 targets, @code{setjmp} doesn't save the registers in 441all circumstances. In those cases, GCC doesn't allocate any variables 442in registers unless they are marked @code{register}. 443 444@end itemize 445 446@item 447@cite{The extent to which suggestions made by using the inline function 448specifier are effective (C99 and C11 6.7.4).} 449 450GCC will not inline any functions if the @option{-fno-inline} option is 451used or if @option{-O0} is used. Otherwise, GCC may still be unable to 452inline a function for many reasons; the @option{-Winline} option may be 453used to determine if a function has not been inlined and why not. 454 455@end itemize 456 457@node Structures unions enumerations and bit-fields implementation 458@section Structures, Unions, Enumerations, and Bit-Fields 459 460@itemize @bullet 461@item 462@cite{A member of a union object is accessed using a member of a 463different type (C90 6.3.2.3).} 464 465The relevant bytes of the representation of the object are treated as 466an object of the type used for the access. @xref{Type-punning}. This 467may be a trap representation. 468 469@item 470@cite{Whether a ``plain'' @code{int} bit-field is treated as a 471@code{signed int} bit-field or as an @code{unsigned int} bit-field 472(C90 6.5.2, C90 6.5.2.1, C99 and C11 6.7.2, C99 and C11 6.7.2.1).} 473 474@opindex funsigned-bitfields 475By default it is treated as @code{signed int} but this may be changed 476by the @option{-funsigned-bitfields} option. 477 478@item 479@cite{Allowable bit-field types other than @code{_Bool}, @code{signed int}, 480and @code{unsigned int} (C99 and C11 6.7.2.1).} 481 482Other integer types, such as @code{long int}, and enumerated types are 483permitted even in strictly conforming mode. 484 485@item 486@cite{Whether atomic types are permitted for bit-fields (C11 6.7.2.1).} 487 488Atomic types are not permitted for bit-fields. 489 490@item 491@cite{Whether a bit-field can straddle a storage-unit boundary (C90 4926.5.2.1, C99 and C11 6.7.2.1).} 493 494Determined by ABI@. 495 496@item 497@cite{The order of allocation of bit-fields within a unit (C90 4986.5.2.1, C99 and C11 6.7.2.1).} 499 500Determined by ABI@. 501 502@item 503@cite{The alignment of non-bit-field members of structures (C90 5046.5.2.1, C99 and C11 6.7.2.1).} 505 506Determined by ABI@. 507 508@item 509@cite{The integer type compatible with each enumerated type (C90 5106.5.2.2, C99 and C11 6.7.2.2).} 511 512@opindex fshort-enums 513Normally, the type is @code{unsigned int} if there are no negative 514values in the enumeration, otherwise @code{int}. If 515@option{-fshort-enums} is specified, then if there are negative values 516it is the first of @code{signed char}, @code{short} and @code{int} 517that can represent all the values, otherwise it is the first of 518@code{unsigned char}, @code{unsigned short} and @code{unsigned int} 519that can represent all the values. 520@c On a few unusual targets with 64-bit int, this doesn't agree with 521@c the code and one of the types accessed via mode attributes (which 522@c are not currently considered extended integer types) may be used. 523@c If these types are made extended integer types, it would still be 524@c the case that -fshort-enums stops the implementation from 525@c conforming to C90 on those targets. 526 527On some targets, @option{-fshort-enums} is the default; this is 528determined by the ABI@. 529 530@end itemize 531 532@node Qualifiers implementation 533@section Qualifiers 534 535@itemize @bullet 536@item 537@cite{What constitutes an access to an object that has volatile-qualified 538type (C90 6.5.3, C99 and C11 6.7.3).} 539 540Such an object is normally accessed by pointers and used for accessing 541hardware. In most expressions, it is intuitively obvious what is a read 542and what is a write. For example 543 544@smallexample 545volatile int *dst = @var{somevalue}; 546volatile int *src = @var{someothervalue}; 547*dst = *src; 548@end smallexample 549 550@noindent 551will cause a read of the volatile object pointed to by @var{src} and store the 552value into the volatile object pointed to by @var{dst}. There is no 553guarantee that these reads and writes are atomic, especially for objects 554larger than @code{int}. 555 556However, if the volatile storage is not being modified, and the value of 557the volatile storage is not used, then the situation is less obvious. 558For example 559 560@smallexample 561volatile int *src = @var{somevalue}; 562*src; 563@end smallexample 564 565According to the C standard, such an expression is an rvalue whose type 566is the unqualified version of its original type, i.e. @code{int}. Whether 567GCC interprets this as a read of the volatile object being pointed to or 568only as a request to evaluate the expression for its side-effects depends 569on this type. 570 571If it is a scalar type, or on most targets an aggregate type whose only 572member object is of a scalar type, or a union type whose member objects 573are of scalar types, the expression is interpreted by GCC as a read of 574the volatile object; in the other cases, the expression is only evaluated 575for its side-effects. 576 577@end itemize 578 579@node Declarators implementation 580@section Declarators 581 582@itemize @bullet 583@item 584@cite{The maximum number of declarators that may modify an arithmetic, 585structure or union type (C90 6.5.4).} 586 587GCC is only limited by available memory. 588 589@end itemize 590 591@node Statements implementation 592@section Statements 593 594@itemize @bullet 595@item 596@cite{The maximum number of @code{case} values in a @code{switch} 597statement (C90 6.6.4.2).} 598 599GCC is only limited by available memory. 600 601@end itemize 602 603@node Preprocessing directives implementation 604@section Preprocessing Directives 605 606@xref{Implementation-defined behavior, , Implementation-defined 607behavior, cpp, The C Preprocessor}, for details of these aspects of 608implementation-defined behavior. 609 610@itemize @bullet 611@item 612@cite{The locations within @code{#pragma} directives where header name 613preprocessing tokens are recognized (C11 6.4, C11 6.4.7).} 614 615@item 616@cite{How sequences in both forms of header names are mapped to headers 617or external source file names (C90 6.1.7, C99 and C11 6.4.7).} 618 619@item 620@cite{Whether the value of a character constant in a constant expression 621that controls conditional inclusion matches the value of the same character 622constant in the execution character set (C90 6.8.1, C99 and C11 6.10.1).} 623 624@item 625@cite{Whether the value of a single-character character constant in a 626constant expression that controls conditional inclusion may have a 627negative value (C90 6.8.1, C99 and C11 6.10.1).} 628 629@item 630@cite{The places that are searched for an included @samp{<>} delimited 631header, and how the places are specified or the header is 632identified (C90 6.8.2, C99 and C11 6.10.2).} 633 634@item 635@cite{How the named source file is searched for in an included @samp{""} 636delimited header (C90 6.8.2, C99 and C11 6.10.2).} 637 638@item 639@cite{The method by which preprocessing tokens (possibly resulting from 640macro expansion) in a @code{#include} directive are combined into a header 641name (C90 6.8.2, C99 and C11 6.10.2).} 642 643@item 644@cite{The nesting limit for @code{#include} processing (C90 6.8.2, C99 645and C11 6.10.2).} 646 647@item 648@cite{Whether the @samp{#} operator inserts a @samp{\} character before 649the @samp{\} character that begins a universal character name in a 650character constant or string literal (C99 and C11 6.10.3.2).} 651 652@item 653@cite{The behavior on each recognized non-@code{STDC #pragma} 654directive (C90 6.8.6, C99 and C11 6.10.6).} 655 656@xref{Pragmas, , Pragmas, cpp, The C Preprocessor}, for details of 657pragmas accepted by GCC on all targets. @xref{Pragmas, , Pragmas 658Accepted by GCC}, for details of target-specific pragmas. 659 660@item 661@cite{The definitions for @code{__DATE__} and @code{__TIME__} when 662respectively, the date and time of translation are not available (C90 6636.8.8, C99 6.10.8, C11 6.10.8.1).} 664 665@end itemize 666 667@node Library functions implementation 668@section Library Functions 669 670The behavior of most of these points are dependent on the implementation 671of the C library, and are not defined by GCC itself. 672 673@itemize @bullet 674@item 675@cite{The null pointer constant to which the macro @code{NULL} expands 676(C90 7.1.6, C99 7.17, C11 7.19).} 677 678In @code{<stddef.h>}, @code{NULL} expands to @code{((void *)0)}. GCC 679does not provide the other headers which define @code{NULL} and some 680library implementations may use other definitions in those headers. 681 682@end itemize 683 684@node Architecture implementation 685@section Architecture 686 687@itemize @bullet 688@item 689@cite{The values or expressions assigned to the macros specified in the 690headers @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>} 691(C90, C99 and C11 5.2.4.2, C99 7.18.2, C99 7.18.3, C11 7.20.2, C11 7.20.3).} 692 693Determined by ABI@. 694 695@item 696@cite{The result of attempting to indirectly access an object with 697automatic or thread storage duration from a thread other than the one 698with which it is associated (C11 6.2.4).} 699 700Such accesses are supported, subject to the same requirements for 701synchronization for concurrent accesses as for concurrent accesses to 702any object. 703 704@item 705@cite{The number, order, and encoding of bytes in any object 706(when not explicitly specified in this International Standard) (C99 707and C11 6.2.6.1).} 708 709Determined by ABI@. 710 711@item 712@cite{Whether any extended alignments are supported and the contexts 713in which they are supported (C11 6.2.8).} 714 715Extended alignments up to @math{2^{28}} (bytes) are supported for 716objects of automatic storage duration. Alignments supported for 717objects of static and thread storage duration are determined by the 718ABI. 719 720@item 721@cite{Valid alignment values other than those returned by an _Alignof 722expression for fundamental types, if any (C11 6.2.8).} 723 724Valid alignments are powers of 2 up to and including @math{2^{28}}. 725 726@item 727@cite{The value of the result of the @code{sizeof} and @code{_Alignof} 728operators (C90 6.3.3.4, C99 and C11 6.5.3.4).} 729 730Determined by ABI@. 731 732@end itemize 733 734@node Locale-specific behavior implementation 735@section Locale-Specific Behavior 736 737The behavior of these points are dependent on the implementation 738of the C library, and are not defined by GCC itself. 739