(This foreword is not a part of American National Standard for Information Systems --- Programming Language C, X3.???-1988.)     American National Standard Programming Language C specifies the syntax and semantics of programs written in the C programming language.  It specifies the C program's interactions with the execution environment via input and output data.  It also specifies restrictions and limits imposed upon conforming implementations of C language translators.     The standard was developed by the X3J11 Technical Committee on the C Programming Language under project 381-D by American National Standards Committee on Computers and Information Processing (X3). SPARC document number 83-079 describes the purpose of this project to ``provide an unambiguous and machine-independent definition of the language C.''     The need for a single clearly defined standard had arisen in the C community due to a rapidly expanding use of the C programming language and the variety of differing translator implementations that had been and were being developed.  The existence of similar but incompatible implementations was a serious problem for program developers who wished to develop code that would compile and execute as expected in several different environments.     Part of this problem could be traced to the fact that implementors did not have an adequate definition of the C language upon which to base their implementations.  The de facto C programming language standard, The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie, is an excellent book; however, it is not precise or complete enough to specify the C language fully.  In addition, the language has grown over years of use to incorporate new ideas in programming and to address some of the weaknesses of the original language.     American National Standard Programming Language C addresses the problems of both the program developer and the translator implementor by specifying the C language precisely.     The work of X3J11 began in the summer of 1983, based on the several documents that were made available to the Committee (see $1.5, Base Documents).  The Committee divided the effort into three pieces: the environment, the language, and the library.  A complete specification in each of these areas is necessary if truly portable programs are to be developed.  Each of these areas is addressed in the Standard.  The Committee evaluated many proposals for additions, deletions, and changes to the base documents during its deliberations.  A concerted effort was made to codify existing practice wherever unambiguous and consistent practice could be identified.  However, where no consistent practice could be identified, the Committee worked to establish clear rules that were consistent with the overall flavor of the language.     This document was approved as an American National Standard by the American National Standards Institute (ANSI) on DD MM, 1988. Suggestions for improvement of this Standard are welcome.  They should be sent to the American National Standards Institute, 1430 Broadway, New York, NY 10018.     The Standard was processed and approved for submittal to ANSI by the American National Standards Committee on Computers and Information Processing, X3.  Committee approval of the Standard does not necessarily imply that all members voted for its approval.  At the time that it approved this Standard, the X3 Committee had the following members:     Organization  Name of Representative  (To be completed on approval of the Standard.)     Technical Committee X3J11 on the C Programming Language had the following members at the time they forwarded this document to X3 for processing as an American National Standard:  Chair Jim Brodie  Vice-Chair Thomas Plum       Plum Hall Secretary P. J. Plauger     Whitesmiths, Ltd.  International Representative P. J. Plauger     Whitesmiths, Ltd. Steve Hersee      Lattice, Inc.  Vocabulary Representative Andrew Johnson    Prime Computer   Environment Subcommittee Chairs Ralph Ryan        Microsoft Ralph Phraner     Phraner Associates  Language Subcommittee Chair Lawrence Rosler   AT&T  Library Subcommittee Chair P. J. Plauger     Whitesmiths, Ltd.  Draft Redactor David F. Prosser  AT&T Lawrence Rosler   AT&T  Rationale Redactor Randy Hudson      Intermetrics, Inc.    In the following list, unmarked names denote principal members and * denotes alternate members.  David F. Prosser, AT&T Steven J. Adamski, AT&T* (X3H2 SQL liaison) Bob Gottlieb, Alliant Computer Systems Kevin Brosnan, Alliant Computer Systems Neal Weidenhofer, Amdahl Philip C. Steel, American Cimflex Eric McGlohon, American Cimflex* Stephen Kafka, Analog Devices Kevin Leary, Analog Devices* Gordon Sterling, Analog Devices* John Peyton, Apollo Computer Elizabeth Crockett, Apple Computers Ed Wells, Arinc Tom Ketterhagen, Arinc* Vaughn Vernon, Aspen Scientific Craig Bordelon, Bell Communications Research Steve Carter, Bell Communications Research* William Puig, Bell Communications Research* Bob Jervis, Borland International Yom-Tov Meged, Boston Systems Office Rose Thomson, Boston Systems Office* Maurice Fathi, COSMIC John Wu, Charles River Data Systems Daniel Mickey, Chemical Abstracts Service Thomas Mimlitch, Chemical Abstracts Service* Alan Losoff, Chicago Research & Trading Group Edward Briggs, Citibank Firmo Freire, Cobra S/A Jim Patterson, Cognos Bruce Tetelman, Columbia U. Center for Computing Terry Moore, CompuDas Mark Barrenechea, Computer Associates George Eberhardt, Computer Innovations Dave Neathery, Computer Innovations* Joseph Bibbo, Computrition Steve Davies, Concurrent Computer Corporation Don Fosbury, Control Data George VandeBunte, Control Data* Lloyd Irons, Cormorant Communications Tom MacDonald, Cray Research Lynne Johnson, Cray Research* Dave Becker, Cray Research* Jean Risley, Custom Development Environments Rex Jaeschke, DEC Professional Mike Terrazas, DECUS Representative Michael Meissner, Data General Mark Harris, Data General* Leonard Ohmes, Datapoint James Stanley, Data Systems Analysts Samuel J. Kendall, Delft Consulting Randy Meyers, Digital Equipment Corporation Art Bjork, Digital Equipment Corporation* Lu Anne Van de Pas, Digital Equipment Corporation* Ben Patel, EDS Richard Relph, EPI Graham Andrews, Edinburgh Portable Compilers Colin McPhail, Edinburgh Portable Compilers* J. Stephen Adamczyk, Edison Design Group Eric Schwarz, Edison Design Group* Dmitry Lenkov, Everest Solutions Frank Farance, Farance Inc. Peter Hayes, Farance Inc.* Florin Jordan, Floradin Philip Provin, General Electric Information Services Liz Sanville, Gould CSD Tina Aleksa, Gould CSD* Thomas Kelly, HCR Corporation Paul Jackson, HCR Corporation* Gary Jeter, Harris Computer Systems Sue Meloy, Hewlett Packard Larry Rosler, Hewlett Packard* Michelle Ruscetta, Hewlett Packard* Thomas E. Osten, Honeywell Information Systems David Kayden, Honeywell Information Systems* Shawn Elliott, IBM Larry Breed, IBM* Mel Goldberg, IBM* Mike Banahan, Instruction Set Clark Nelson, Intel Dan Lau, Intel* John Wolfe, InterACT Lillian Toll, InterACT* Randy Hudson, Intermetrics Keith Winter, International Computers Ltd. Honey M. Schrecker, International Computers Ltd.* Jim Brodie, J. Brodie & Associates Jacklin Kotikian, Kendall Square Research W. Peter Hesse, LSI Logic Europe Ltd. John Kaminski, Language Processors Inc. David Yost, Laurel Arts Mike Branstetter, Lawrence Livermore National Laboratory Bob Weaver, Los Alamos National Laboratory Lidia Eberhart, Modcomp Robert Sherry, Manx Software Courtney Meissen, Mark Williams Co. Patricia Jenkins, Masscomp Dave Hinman, Masscomp* Michael Kearns, MetaLink Tom Pennello, MetaWare Incorporated David F. Weil, Microsoft Mitch Harder, Microsoft* Kim Kempf, Microware Systems Shane McCarron, Minnesota Educational Computing Bruce Olsen, Mosaic Technologies Michael Paton, Motorola Rick Schubert, NCR Brian Johnson, NCR* Joseph Mueller, National Semiconductor Derek Godfrey, National Semiconductor* Jim Upperman, National Bureau of Standards James W. Williams, Naval Research Laboratory Lisa Simon, OCLC Paul Amaranth, Oakland University August R. Hansen, Omniware Michael Rolle, Oracle Carl Ellis, Oregon Software Barry Hedquist, Perennial Sassan Hazeghi, Peritus International James Holmlund, Peritus International* Thomas Plum, Plum Hall Christopher Skelly, Plum Hall* Andrew Johnson, Prime Computer Fran Litterio, Prime Computer* Daniel J. Conrad, Prismatics David Fritz, Production Languages Kenneth Pugh, Pugh Killeen Ed Ramsey, Purdue University Stephen Roberts, Purdue University* Kevin Nolan, Quantitative Technology Corp. Robert Mueller, Quantitative Technology Corp.* Chris DeVoney, Que Corporation Jon Tulk, Rabbit Software Terry Colligan, Rational Systems Daniel Saks, Saks & Associates Nancy Saks, Saks & Associates* Oliver Bradley, SAS Institute Alan Beale, SAS Institute* Larry Jones, SDRC Donald Kossman, SEI Information Technology Kenneth Harrenstien, SRI International Larry Rosenthal, Sierra Systems Phil Hempfner, Southern Bell Telephone Purshotam Rajani, Spruce Technology Savu Savulescu, Stagg Systems Peter Darnell, Stellar Computer Lee W. Cooprider, Stellar Computer* Paul Gilmartin, Storage Technology Corp. Steve Muchnick, Sun Microsystems Chuck Rasbold, Supercomputer Systems, Inc. Kelly O'Hair, Supercomputer Systems, Inc.* Henry Richardson, Tandem John M. Hausman, Tandem* Samuel Harbison, Tartan Laboratories Michael S. Ball, TauMetric Carl Sutton, Tektronix Jim Besemer, Tektronix* Reid Tatge, Texas Instruments Ed Brower, Tokheim Robert Mansfield, Tokheim* Monika Khushf, Tymlabs Morgan Jones, Tymlabs* Don Bixler, Unisys Steve Bartels, Unisys* Glenda Berkheimer, Unisys* Annice Jackson, Unisys* Fred Blonder, University of Maryland Fred Schwarz, University of Michigan R. Jordan Kreindler, University of Southern California CTC Mike Carmody, University of Waterloo Douglas Gwyn, US Army BRL (IEEE P1003 liaison) C. Dale Pierce, US Army Management Engineering* John C. Black, VideoFinancial Joseph Musacchia, Wang Labs Fred Rozakis, Wang Labs* P. J. Plauger, Whitesmiths, Ltd. Kim Leeper, Wick Hill Mark Wittenberg, Zehntel Jim Balter Robert Bradbury Edward Chin Neil Daniels Stephen Desofi Michael Duffy Phillip Escue Ralph Phraner D. Hugh Redelmeier Arnold Davi Robbins Roger Wilks Michael J. Young   purpose: 1.1 scope: 1.2 references: 1.3 organization of the document: 1.4 base documents: 1.5 definitions of terms: 1.6 compliance: 1.7 translation environment: 2. execution environment: 2. separate compilation: 2.1.1.1 separate translation: 2.1.1.1 source file: 2.1.1.1 translation unit: 2.1.1.1 program execution: 2.1.2.3 side effects: 2.1.2.3 sequence point: 2.1.2.3 character set: 2.2.1 signals: 2.2.3 interrupts: 2.2.3 syntax notation: 3. lexical elements: 3.1 comment: 3.1 white space: 3.1 list of keywords: 3.1.1 reserved words: 3.1.1 underscore character: 3.1.2 enumeration constant: 3.1.2 length of names: 3.1.2 internal name, length of: 3.1.2 external name, length of: 3.1.2 function name, length of: 3.1.2 scopes: 3.1.2.1 prototype, function: 3.1.2.1 function scope: 3.1.2.1 file scope: 3.1.2.1 block scope: 3.1.2.1 block structure: 3.1.2.1 function prototype scope: 3.1.2.1 linkage: 3.1.2.2 external linkage: 3.1.2.2 internal linkage: 3.1.2.2 no linkage: 3.1.2.2 name spaces: 3.1.2.3 named label: 3.1.2.3 structure tag: 3.1.2.3 union tag: 3.1.2.3 enumeration tag: 3.1.2.3 structure member name: 3.1.2.3 union member name: 3.1.2.3 storage duration: 3.1.2.4 static storage duration: 3.1.2.4 automatic storage duration: 3.1.2.4 types: 3.1.2.5 object types: 3.1.2.5 function types: 3.1.2.5 incomplete types: 3.1.2.5 char type: 3.1.2.5 signed character: 3.1.2.5 signed char type: 3.1.2.5 short type: 3.1.2.5 long type: 3.1.2.5 unsigned type: 3.1.2.5 float type: 3.1.2.5 double type: 3.1.2.5 long double type: 3.1.2.5 basic types: 3.1.2.5 character types: 3.1.2.5 enumerated type: 3.1.2.5 void type: 3.1.2.5 derived types: 3.1.2.5 integral types: 3.1.2.5 arithmetic types: 3.1.2.5 scalar types: 3.1.2.5 aggregate types: 3.1.2.5 constants: 3.1.3 floating constant: 3.1.3.1 double constant: 3.1.3.1 integer constant: 3.1.3.2 decimal constant: 3.1.3.2 octal constant: 3.1.3.2 hexadecimal constant: 3.1.3.2 unsigned constant: 3.1.3.2 long constant: 3.1.3.2 enumeration constant: 3.1.3.3 character constant: 3.1.3.4 backslash character: 3.1.3.4  escape character: 3.1.3.4 escape sequence: 3.1.3.4 string literal: 3.1.4 character string: 3.1.4 operator: 3.1.5 evaluation: 3.1.5 operand: 3.1.5 punctuator: 3.1.6 character-integer conversion: 3.2.1.1 integer-character conversion: 3.2.1.1 integral promotions: 3.2.1.1 integer-long conversion: 3.2.1.1 signed character: 3.2.1.1 unsigned-integer conversion: 3.2.1.2 integer-unsigned conversion: 3.2.1.2 long-unsigned conversion: 3.2.1.2 long-integer conversion: 3.2.1.2 floating-integer conversion: 3.2.1.3 integer-floating conversion: 3.2.1.3 float-double conversion: 3.2.1.4 double-float conversion: 3.2.1.4 arithmetic conversions: 3.2.1.5 type conversion rules: 3.2.1.5 lvalue: 3.2.2.1 function designator: 3.2.2.1 conversion of array: 3.2.2.1 conversion of function name: 3.2.2.1 void type: 3.2.2.2 pointer-pointer conversion: 3.2.2.3 integer-pointer conversion: 3.2.2.3 null pointer: 3.2.2.3 expression: 3.3 precedence of operators: 3.3 associativity of operators: 3.3 order of evaluation of expressions: 3.3 order of evaluation: 3.3 bitwise operators: 3.3 exceptions: 3.3 primary expression: 3.3.1 type of string: 3.3.1 parenthesized expression: 3.3.1 subscript operator: 3.3.2 function call: 3.3.2 structure member operator: 3.3.2 structure pointer operator: 3.3.2 ++ increment operator: 3.3.2 -- decrement operator: 3.3.2 array, explanation of subscripting: 3.3.2.1 subscripting, explanation of: 3.3.2.1 multi-dimensional array: 3.3.2.1 storage order of array: 3.3.2.1 function call: 3.3.2.2 implicit declaration of function: 3.3.2.2 function argument: 3.3.2.2 call by value: 3.3.2.2 recursion: 3.3.2.2 structure reference: 3.3.2.3 union reference: 3.3.2.3 common initial sequence: 3.3.2.3 postfix ++ and --: 3.3.2.4 -- decrement operator: 3.3.2.4 unary expression: 3.3.3 ++ increment operator: 3.3.3 -- decrement operator: 3.3.3 sizeof operator: 3.3.3 & address operator: 3.3.3 * indirection operator: 3.3.3 + unary plus operator: 3.3.3 - unary minus operator: 3.3.3 ~ bitwise complement operator: 3.3.3 ! logical negation operator: 3.3.3 ++ increment operator: 3.3.3.1 prefix ++ and --: 3.3.3.1 -- decrement operator: 3.3.3.1 + unary plus operator: 3.3.3.3 - unary minus operator: 3.3.3.3 ~ bitwise complement operator: 3.3.3.3 ! logical negation operator: 3.3.3.3 byte: 3.3.3.4 storage allocator: 3.3.3.4 cast expression: 3.3.4 cast operator: 3.3.4 explicit conversion operator: 3.3.4 cast operator: 3.3.4 pointer conversion: 3.3.4 explicit conversion operator: 3.3.4 pointer-integer conversion: 3.3.4 integer-pointer conversion: 3.3.4 alignment restriction: 3.3.4 arithmetic operators: 3.3.5 multiplicative operators: 3.3.5 * multiplication operator: 3.3.5 / division operator: 3.3.5 % modulus operator: 3.3.5 additive operators: 3.3.6 + addition operator: 3.3.6 - subtraction operator: 3.3.6 pointer arithmetic: 3.3.6 pointer arithmetic: 3.3.6 shift operators: 3.3.7 << left shift operator: 3.3.7 >> right shift operator: 3.3.7 relational operators: 3.3.8 < less than operator: 3.3.8 > greater than operator: 3.3.8 <= less than or equal to operator: 3.3.8 >= greater than or equal to operator: 3.3.8 pointer comparison: 3.3.8 equality operators: 3.3.9 == equality operator: 3.3.9 != inequality operator: 3.3.9 & bitwise AND operator: 3.3.10 ^ bitwise exclusive OR operator: 3.3.11 | bitwise inclusive OR operator: 3.3.12 && logical AND operator: 3.3.13 || logical OR operator: 3.3.14 ?: conditional expression: 3.3.15 assignment operators: 3.3.16 assignment expression: 3.3.16 simple assignment: 3.3.16.1 conversion by assignment: 3.3.16.1 compound assignment: 3.3.16.2 comma operator: 3.3.17 constant expression: 3.4 permitted form of initializer: 3.4 declarations: 3.5 storage-class specifier: 3.5.1 storage-class declaration: 3.5.1 typedef declaration: 3.5.1 extern storage class: 3.5.1 static storage class: 3.5.1 auto storage class: 3.5.1 register storage class: 3.5.1 type specifier: 3.5.2 void type: 3.5.2 char type: 3.5.2 short type: 3.5.2 int type: 3.5.2 long type: 3.5.2 float type: 3.5.2 double type: 3.5.2 signed type: 3.5.2 unsigned type: 3.5.2 structure declaration: 3.5.2.1 union declaration: 3.5.2.1 bit-field declaration: 3.5.2.1 bit-field: 3.5.2.1 member alignment: 3.5.2.1 enumeration: 3.5.2.2 enum-specifier: 3.5.2.2 enumerator: 3.5.2.2 structure tag: 3.5.2.3 union tag: 3.5.2.3 structure content: 3.5.2.3 union content: 3.5.2.3 enumeration content: 3.5.2.3 self-referential structure: 3.5.2.3 type qualifier: 3.5.3 const type qualifier: 3.5.3 volatile type qualifier: 3.5.3 declarator: 3.5.4 type declaration: 3.5.4 declaration of pointer: 3.5.4.1 array declaration: 3.5.4.2 declaration of function: 3.5.4.3 type names: 3.5.5 abstract declarator: 3.5.5 typedef declaration: 3.5.6 initialization: 3.5.7 initialization of statics: 3.5.7 implicit initialization: 3.5.7 default initialization: 3.5.7 initialization of automatics: 3.5.7 aggregate initialization: 3.5.7 array initialization: 3.5.7 structure initialization: 3.5.7 character array initialization: 3.5.7 wchar_t array initialization: 3.5.7 statements: 3.6 sequencing of statements: 3.6 full expression: 3.6 labeled statement: 3.6.1 named label: 3.6.1 case label: 3.6.1 default label: 3.6.1 compound statement: 3.6.2 block: 3.6.2 block structure: 3.6.2 initialization in blocks: 3.6.2 expression statement: 3.6.3 null statement: 3.6.3 empty statement: 3.6.3 if-else statement: 3.6.4.1 switch statement: 3.6.4.2 switch body: 3.6.4.2 loop body: 3.6.5 while statement: 3.6.5.1 do statement: 3.6.5.2 for statement: 3.6.5.3 goto statement: 3.6.6.1 continue statement: 3.6.6.2 break statement: 3.6.6.3 return statement: 3.6.6.4 type conversion by return: 3.6.6.4 conversion by return: 3.6.6.4 external definition: 3.7 function definition: 3.7.1 parameter: 3.7.1 array argument: 3.7.1 function name argument: 3.7.1 pointer to function: 3.7.1 object definitions: 3.7.2 scope of externals: 3.7.2 tentative definition: 3.7.2 preprocessing directives: 3.8 macro preprocessor: 3.8 preprocessing directive lines: 3.8 conditional inclusion: 3.8.1 #if: 3.8.1 #elif 3.8.1 #ifdef: 3.8.1 #ifndef: 3.8.1 #else: 3.8.1 #endif: 3.8.1 #include: 3.8.2 source file inclusion: 3.8.2 macro replacement: 3.8.3 object-like macro: 3.8.3 function-like macro: 3.8.3 macro name: 3.8.3 #define: 3.8.3 macro parameters: 3.8.3 macro invocation: 3.8.3 argument substitution: 3.8.3.1 # operator: 3.8.3.2 ## operator: 3.8.3.3 rescanning and replacement: 3.8.3.4 macro definition scope: 3.8.3.5 #undef: 3.8.3.5 #line: 3.8.4 error directive: 3.8.5 pragma directive: 3.8.6 null directive: 3.8.7 introduction: 4.1 string definition: 4.1.1 letter definition: 4.1.1 decimal-point definition: 4.1.1 reserved identifier: 4.1.2 printing character: 4.3 control character: 4.3 variable arguments: 4.8 unbuffered stream: 4.9.3 fully buffered stream: 4.9.3 line buffered stream: 4.9.3 appendices: A. language syntax summary: A.1 sequence points: A.2 library summary: A.3 implementation limits: A.4 warnings: A.5 portability: A.6 order of evaluation: A.6.1 machine dependency: A.6.3 restrictions on registers: A.6.3.7 function pointer casts: A.6.5.7 bit-field types: A.6.5.8 fortran keyword: A.6.5.9 asm keyword: A.6.5.10 multiple external definitions: A.6.5.11 empty macro arguments: A.6.5.12 predefined macro names: A.6.5.13 signal handler arguments: A.6.5.14 stream types: A.6.5.15 file-opening modes: A.6.5.15 file position indicator: A.6.5.16 foreword: A.7   1. INTRODUCTION  1.1 PURPOSE     This Standard specifies the form and establishes the interpretation    of programs written in the C programming language./1/  1.2 SCOPE     This Standard specifies:    * the representation of C programs;    * the syntax and constraints of the C language;    * the semantic rules for interpreting C programs;    * the representation of input data to be processed by C programs;    * the representation of output data produced by C programs;    * the restrictions and limits imposed by a conforming implementation of C.        This Standard does not specify:    * the mechanism by which C programs are transformed for use by a    data-processing system;   * the mechanism by which C programs are invoked for use by a    data-processing system;   * the mechanism by which input data are transformed for use by a C program;    * the mechanism by which output data are transformed after being    produced by a C program;   * the size or complexity of a program and its data that will exceed    the capacity of any specific data-processing system or the capacity of    a particular processor;   * all minimal requirements of a data-processing system that is    capable of supporting a conforming implementation.   1.3 REFERENCES   1. ``The C Reference Manual'' by Dennis M. Ritchie, a version of     which was published in The C Programming Language by Brian     W. Kernighan and Dennis M. Ritchie, Prentice-Hall, Inc., (1978).     Copyright owned by AT&T.   2. 1984 /usr/group Standard by the /usr/group Standards Committee,     Santa Clara, California, USA (November, 1984).   3. American National Dictionary for Information Processing Systems,     Information Processing Systems Technical Report ANSI X3/TR-1-82 (1982).   4. ISO 646-1983 Invariant Code Set.     5. IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985).     6. ISO 4217 Codes for the Representation of Currency and Funds.     1.4 ORGANIZATION OF THE DOCUMENT     This document is divided into four major sections:    1. this introduction;    2. the characteristics of environments that translate and execute C programs;    3. the language syntax, constraints, and semantics;    4. the library facilities.    Examples are provided to illustrate possible forms of the constructions described.  Footnotes are provided to emphasize consequences of the rules described in the section or elsewhere in the Standard.  References are used to refer to other related sections.  A set of appendices summarizes information contained in the Standard. The abstract, the foreword, the examples, the footnotes, the references, and the appendices are not part of the Standard.  1.5 BASE DOCUMENTS  The language section ($3) is derived from ``The C Reference Manual'' by Dennis M. Ritchie, a version of which was published as Appendix A of The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie, Prentice-Hall, Inc., 1978; copyright owned by AT&T.  The library section ($4) is based on the 1984 /usr/group Standard by the /usr/group Standards Committee, Santa Clara, California, USA (November 14, 1984).  1.6 DEFINITIONS OF TERMS     In this Standard, ``shall'' is to be interpreted as a requirement on an implementation or on a program; conversely, ``shall not'' is to be interpreted as a prohibition.  The following terms are used in this document:    * Implementation --- a particular set of software, running in a    particular translation environment under particular control options,    that performs translation of programs for, and supports execution of    functions in, a particular execution environment.   * Bit --- the unit of data storage in the execution environment large    enough to hold an object that may have one of two values.  It need not    be possible to express the address of each individual bit of an    object.   * Byte --- the unit of data storage in the execution environment    large enough to hold any member of the basic character set of the    execution environment.  It shall be possible to express the address of    each individual byte of an object uniquely.  A byte is composed of a    contiguous sequence of bits, the number of which is    implementation-defined.  The least significant bit is called the    low-order bit; the most significant bit is called the high-order bit.   * Object --- a region of data storage in the execution environment,    the contents of which can represent values.  Except for bit-fields,    objects are composed of contiguous sequences of one or more bytes, the    number, order, and encoding of which are either explicitly specified    or implementation-defined.   * Character --- a single byte representing a member of the basic    character set of either the source or the execution environment.   * Multibyte character --- a sequence of one or more bytes    representing a member of the extended character set of either the    source or the execution environment.  The extended character set is a    superset of the basic character set.   * Alignment --- a requirement that objects of a particular type be    located on storage boundaries with addresses that are particular    multiples of a byte address.   * Argument --- an expression in the comma-separated list bounded by    the parentheses in a function call expression, or a sequence of    preprocessing tokens in the comma-separated list bounded by the    parentheses in a function-like macro invocation.  Also known as    ``actual argument'' or ``actual parameter.''   * Parameter --- an object declared as part of a function declaration    or definition that acquires a value on entry to the function, or an    identifier from the comma-separated list bounded by the parentheses    immediately following the macro name in a function-like macro    definition.  Also known as ``formal argument'' or ``formal    parameter.''   * Unspecified behavior --- behavior, for a correct program construct    and correct data, for which the Standard imposes no requirements.   * Undefined behavior --- behavior, upon use of a nonportable or    erroneous program construct, of erroneous data, or of    indeterminately-valued objects, for which the Standard imposes no    requirements.  Permissible undefined behavior ranges from ignoring the    situation completely with unpredictable results, to behaving during    translation or program execution in a documented manner characteristic    of the environment (with or without the issuance of a diagnostic    message), to terminating a translation or execution (with the issuance    of a diagnostic message).     If a ``shall'' or ``shall not'' requirement that appears outside of    a constraint is violated, the behavior is undefined.  Undefined     behavior is otherwise indicated in this Standard by the words    ``undefined behavior'' or by the omission of any explicit definition    of behavior.  There is no difference in emphasis among these three;    they all describe ``behavior that is undefined.''   * Implementation-defined behavior --- behavior, for a correct program    construct and correct data, that depends on the characteristics of the    implementation and that each implementation shall document.   * Locale-specific behavior --- behavior that depends on local    conventions of nationality, culture, and language that each    implementation shall document.   * Diagnostic message --- a message belonging to an    implementation-defined subset of the implementation's message output.   * Constraints --- syntactic and semantic restrictions by which the    exposition of language elements is to be interpreted.   * Implementation limits --- restrictions imposed upon programs by the    implementation.   * Forward references --- references to later sections of the Standard    that contain additional information relevant to this section.     Other terms are defined at their first appearance, indicated by italic    type.  Terms explicitly defined in this Standard are not to be    presumed to refer implicitly to similar terms defined elsewhere.     Terms not defined in this Standard are to be interpreted according to    the American National Dictionary for Information Processing Systems,    Information Processing Systems Technical Report ANSI X3/TR-1-82 (1982).  Forward references: localization ($4.4).    "Examples"     An example of unspecified behavior is the order in which the    arguments to a function are evaluated.     An example of undefined behavior is the behavior on integer overflow.     An example of implementation-defined behavior is the propagation of    the high-order bit when a signed integer is shifted right.     An example of locale-specific behavior is whether the islower    function returns true for characters other than the 26 lower-case    English letters.  Forward references: bitwise shift operators ($3.3.7), expressions ($3.3), function calls ($3.3.2.2), the islower function ($4.3.1.6).   1.7 COMPLIANCE     A strictly conforming program shall use only those features of the language and library specified in this Standard.  It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.     The two forms of conforming implementation are hosted and freestanding.  A conforming hosted implementation shall accept any strictly conforming program.  A conforming freestanding implementation shall accept any strictly conforming program in which the use of the features specified in the library section ($4) is confined to the contents of the standard headers <float.h> , <limits.h> , <stdarg.h> , and <stddef.h> .  A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program.     A conforming program is one that is acceptable to a conforming implementation./2/     An implementation shall be accompanied by a document that defines all implementation-defined characteristics and all extensions.  Forward references: limits <float.h> and <limits.h> ($4.1.4), variable arguments <stdarg.h> ($4.8), common definitions <stddef.h> ($4.1.5).   1.8 FUTURE DIRECTIONS     With the introduction of new devices and extended character sets, new features may be added to the Standard.  Subsections in the language and library sections warn implementors and programmers of usages which, though valid in themselves, may conflict with future additions.     Certain features are obsolescent , which means that they may be considered for withdrawal in future revisions of the Standard.  They are retained in the Standard because of their widespread use, but their use in new implementations (for implementation features) or new programs (for language or library features) is discouraged.  Forward references: future language directions ($3.9.9), future library directions ($4.13).  1.9 ABOUT THIS DRAFT     Symbols in the right margin mark substantive differences between this draft and its predecessor (ANSI X3J11/88-001, January 11, 1988). A plus sign indicates an addition, a minus sign a deletion, and a vertical bar a replacement.     This section and the difference marks themselves will not appear in the published document.   2. ENVIRONMENT     An implementation translates C source files and executes C programs in two data-processing-system environments, which will be called the translation environment and the execution environment in this Standard.  Their characteristics define and constrain the results of executing conforming C programs constructed according to the syntactic and semantic rules for conforming implementations.  Forward references: In the environment section ($2), only a few of many possible forward references have been noted.   2.1 CONCEPTUAL MODELS  2.1.1 Translation environment  2.1.1.1 Program structure     A C program need not all be translated at the same time.  The text of the program is kept in units called source files in this Standard. A source file together with all the headers and source files included via the preprocessing directive #include , less any source lines skipped by any of the conditional inclusion preprocessing directives, is called a translation unit. Previously translated translation units may be preserved individually or in libraries.  The separate translation units of a program communicate by (for example) calls to functions whose identifiers have external linkage, by manipulation of objects whose identifiers have external linkage, and by manipulation of data files.  Translation units may be separately translated and then later linked to produce an executable program.  Forward references: conditional inclusion ($3.8.1), linkages of identifiers ($3.1.2.2), source file inclusion ($3.8.2).  2.1.1.2 Translation phases     The precedence among the syntax rules of translation is specified by the following phases./3/   1. Physical source file characters are mapped to the source character     set (introducing new-line characters for end-of-line indicators) if     necessary.  Trigraph sequences are replaced by corresponding     single-character internal representations.   2. Each instance of a new-line character and an immediately preceding     backslash character is deleted, splicing physical source lines to form     logical source lines.  A source file that is not empty shall end in a     new-line character, which shall not be immediately preceded by a     backslash character.   3. The source file is decomposed into preprocessing tokens/4/ and     sequences of white-space characters (including comments).  A source     file shall not end in a partial preprocessing token or comment.  Each     comment is replaced by one space character.  New-line characters are     retained.  Whether each nonempty sequence of other white-space     characters is retained or replaced by one space character is     implementation-defined.   4. Preprocessing directives are executed and macro invocations are     expanded.  A #include preprocessing directive causes the named header     or source file to be processed from phase 1 through phase 4,     recursively.   5. Each escape sequence in character constants and string literals is     converted to a member of the execution character set.   6. Adjacent character string literal tokens are concatenated and     adjacent wide string literal tokens are concatenated.   7. White-space characters separating tokens are no longer     significant.  Preprocessing tokens are converted into tokens.  The     resulting tokens are syntactically and semantically analyzed and     translated.   8. All external object and function references are resolved.  Library     components are linked to satisfy external references to functions and     objects not defined in the current translation.  All such translator     output is collected into a program image which contains information     needed for execution in its execution environment.  Forward references: lexical elements ($3.1), preprocessing directives ($3.8), trigraph sequences ($2.2.1.1).  2.1.1.3 Diagnostics     A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) for every translation unit that contains a violation of any syntax rule or constraint.  Diagnostic messages need not be produced in other circumstances.  2.1.2 Execution environments     Two execution environments are defined: freestanding and hosted. In both cases, program startup occurs when a designated C function is called by the execution environment.  All objects in static storage shall be initialized (set to their initial values) before program startup.  The manner and timing of such initialization are otherwise unspecified.  Program termination returns control to the execution environment.  Forward references: initialization ($3.5.7).    2.1.2.1 Freestanding environment     In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined.  There are otherwise no reserved external identifiers.  Any library facilities available to a freestanding program are implementation-defined.     The effect of program termination in a freestanding environment is implementation-defined.  2.1.2.2 Hosted environment     A hosted environment need not be provided, but shall conform to the following specifications if present.  "Program startup"     The function called at program startup is named main .  The implementation declares no prototype for this function.  It can be defined with no parameters:           int main(void) { /*...*/ }  or with two parameters (referred to here as argc and argv , though any names may be used, as they are local to the function in which they are declared):           int main(int argc, char *argv[]) { /*...*/ }      If they are defined, the parameters to the main function shall obey the following constraints:   * The value of argc shall be nonnegative.     * argv[argc] shall be a null pointer.     * If the value of argc is greater than zero, the array members    argv[0] through argv[argc-1] inclusive shall contain pointers to    strings, which are given implementation-defined values by the host    environment prior to program startup.  The intent is to supply to the    program information determined prior to program startup from elsewhere    in the hosted environment.  If the host environment is not capable of    supplying strings with letters in both upper-case and lower-case, the    implementation shall ensure that the strings are received in    lower-case.   * If the value of argc is greater than zero, the string pointed to by    argv[0] represents the program name ;argv[0][0] shall be the null    character if the program name is not available from the host    environment.  If the value of argc is greater than one, the strings    pointed to by argv[1] through argv[argc-1] represent the program    parameters .   * The parameters argc and argv and the strings pointed to by the argv    array shall be modifiable by the program, and retain their last-stored    values between program startup and program termination.  "Program execution"     In a hosted environment, a program may use all the functions, macros, type definitions, and objects described in the library section ($4).  "Program termination"     A return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument.  If the main function executes a return that specifies no value, the termination status returned to the host environment is undefined.  Forward references: definition of terms ($4.1.1), the exit function ($4.10.4.3).   2.1.2.3 Program execution     The semantic descriptions in this Standard describe the behavior of an abstract machine in which issues of optimization are irrelevant.     Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects ,which are changes in the state of the execution environment. Evaluation of an expression may produce side effects.  At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.     In the abstract machine, all expressions are evaluated as specified by the semantics.  An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).     When the processing of the abstract machine is interrupted by receipt of a signal, only the values of objects as of the previous sequence point may be relied on.  Objects that may be modified between the previous sequence point and the next sequence point need not have received their correct values yet.     An instance of each object with automatic storage duration is associated with each entry into a block.  Such an object exists and retains its last-stored value during the execution of the block and while the block is suspended (by a call of a function or receipt of a signal).     The least requirements on a conforming implementation are:    * At sequence points, volatile objects are stable in the sense that    previous evaluations are complete and subsequent evaluations have not    yet occurred.   * At program termination, all data written into files shall be    identical to the result that execution of the program according to the    abstract semantics would have produced.   * The input and output dynamics of interactive devices shall take    place as specified in $4.9.3.  The intent of these requirements is    that unbuffered or line-buffered output appear as soon as possible, to    ensure that prompting messages actually appear prior to a program    waiting for input.     What constitutes an interactive device is implementation-defined.     More stringent correspondences between abstract and actual    semantics may be defined by each implementation.  "Examples"     An implementation might define a one-to-one correspondence between abstract and actual semantics: at every sequence point, the values of the actual objects would agree with those specified by the abstract semantics.  The keyword volatile would then be redundant.     Alternatively, an implementation might perform various optimizations within each translation unit, such that the actual semantics would agree with the abstract semantics only when making function calls across translation unit boundaries.  In such an implementation, at the time of each function entry and function return where the calling function and the called function are in different translation units, the values of all externally linked objects and of all objects accessible via pointers therein would agree with the abstract semantics.  Furthermore, at the time of each such function entry the values of the parameters of the called function and of all objects accessible via pointers therein would agree with the abstract semantics.  In this type of implementation, objects referred to by interrupt service routines activated by the signal function would require explicit specification of volatile storage, as well as other implementation-defined restrictions.     In executing the fragment            char c1, c2;          /*...*/          c1 = c1 + c2;  the ``integral promotions'' require that the abstract machine promote the value of each variable to int size and then add the two int s and truncate the sum.  Provided the addition of two char s can be done without creating an overflow exception, the actual execution need only produce the same result, possibly omitting the promotions.     Similarly, in the fragment            float f1, f2;          double d;          /*...*/          f1 = f2 * d;  the multiplication may be executed using single-precision arithmetic if the implementation can ascertain that the result would be the same as if it were executed using double-precision arithmetic (for example, if d were replaced by the constant 2.0, which has type double ). Alternatively, an operation involving only int s or float s may be executed using double-precision operations if neither range nor precision is lost thereby.  Forward references: compound statement, or block ($3.6.2), files ($4.9.3), sequence points ($3.3, $3.6), the signal function ($4.7), type qualifiers ($3.5.3).   2.2 ENVIRONMENTAL CONSIDERATIONS  2.2.1 Character sets     Two sets of characters and their associated collating sequences shall be defined: the set in which source files are written, and the set interpreted in the execution environment.  The values of the members of the execution character set are implementation-defined; any additional members beyond those required by this section are locale-specific.     In a character constant or string literal, members of the execution character set shall be represented by corresponding members of the source character set or by escape sequences consisting of the backslash \ followed by one or more characters.  A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string literal.     Both the basic source and basic execution character sets shall have at least the following members: the 26 upper-case letters of the English alphabet           A  B  C  D  E  F  G  H  I  J  K  L  M          N  O  P  Q  R  S  T  U  V  W  X  Y  Z  the 26 lower-case letters of the English alphabet            a  b  c  d  e  f  g  h  i  j  k  l  m          n  o  p  q  r  s  t  u  v  w  x  y  z  the 10 decimal digits            0  1  2  3  4  5  6  7  8  9  the following 29 graphic characters            !  "  #  %  &  '  (  )  *  +  ,  -  .  /  :          ;  <  =  >  ?  [  \  ]  ^  _  {  |  }  ~  the space character, and control characters representing horizontal tab, vertical tab, and form feed.  In both the source and execution basic character sets, the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous.  In source files, there shall be some way of indicating the end of each line of text; this Standard treats such an end-of-line indicator as if it were a single new-line character.  In the execution character set, there shall be control characters representing alert, backspace, carriage return, and new line.  If any other characters are encountered in a source file (except in a preprocessing token that is never converted to a token, a character constant, a string literal, or a comment), the behavior is undefined.  Forward references: character constants ($3.1.3.4), preprocessing directives ($3.8), string literals ($3.1.4), comments ($3.1.9).   2.2.1.1 Trigraph sequences     All occurrences in a source file of the following sequences of three characters (called trigraph sequences /5/)are replaced with the corresponding single character.           ??=      #          ??(      [          ??/      \          ??)      ]          ??'      ^          ??<      {          ??!      |          ??>      }          ??-      ~  No other trigraph sequences exist.  Each ? that does not begin one of the trigraphs listed above is not changed.  Example     The following source line            printf("Eh???/n");  becomes (after replacement of the trigraph sequence ??/ )            printf("Eh?\n");   2.2.1.2 Multibyte characters     The source character set may contain multibyte characters, used to represent members of the extended character set.  The execution character set may also contain multibyte characters, which need not have the same encoding as for the source character set.  For both character sets, the following shall hold:   * The single-byte characters defined in $2.2.1 shall be present.     * The presence, meaning, and representation of any additional members    is locale-specific.   * A multibyte character may have a state-dependent encoding ,wherein    each sequence of multibyte characters begins in an initial shift state    and enters other implementation-defined shift states when specific    multibyte characters are encountered in the sequence.  While in the    initial shift state, all single-byte characters retain their usual    interpretation and do not alter the shift state.  The interpretation    for subsequent bytes in the sequence is a function of the current    shift state.   * A byte with all bits zero shall be interpreted as a null character    independent of shift state.   * A byte with all bits zero shall not occur in the second or    subsequent bytes of a multibyte character.     For the source character set, the following shall hold:    * A comment, string literal, character constant, or header name shall    begin and end in the initial shift state.   * A comment, string literal, character constant, or header name shall    consist of a sequence of valid multibyte characters.   2.2.2 Character display semantics     The active position is that location on a display device where the next character output by the fputc function would appear.  The intent of writing a printable character (as defined by the isprint function) to a display device is to display a graphic representation of that character at the active position and then advance the active position to the next position on the current line.  The direction of printing is locale-specific.  If the active position is at the final position of a line (if there is one), the behavior is unspecified.     Alphabetic escape sequences representing nongraphic characters in the execution character set are intended to produce actions on display devices as follows: ( alert ) Produces an audible or visible alert. The active position shall not be changed.  ( backspace ) Moves the active position to the previous position on the current line.  If the active position is at the initial position of a line, the behavior is unspecified.  ( "form feed" ) Moves the active position to the initial position at the start of the next logical page.  ( "new line" ) Moves the active position to the initial position of the next line.   ( "carriage return" ) Moves the active position to the initial position of the current line.  ( "horizontal tab" ) Moves the active position to the next horizontal tabulation position on the current line.  If the active position is at or past the last defined horizontal tabulation position, the behavior is unspecified.  ( "vertical tab" ) Moves the active position to the initial position of the next vertical tabulation position.  If the active position is at or past the last defined vertical tabulation position, the behavior is unspecified.     Each of these escape sequences shall produce a unique implementation-defined value which can be stored in a single char object.  The external representations in a text file need not be identical to the internal representations, and are outside the scope of this Standard.  Forward references: the fputc function ($4.9.7.3), the isprint function ($4.3.1.7).   2.2.3 Signals and interrupts     Functions shall be implemented such that they may be interrupted at any time by a signal, or may be called by a signal handler, or both, with no alteration to earlier, but still active, invocations' control flow (after the interruption), function return values, or objects with automatic storage duration.  All such objects shall be maintained outside the function image (the instructions that comprise the executable representation of a function) on a per-invocation basis.     The functions in the standard library are not guaranteed to be reentrant and may modify objects with static storage duration.   2.2.4 Environmental limits     Both the translation and execution environments constrain the implementation of language translators and libraries.  The following summarizes the environmental limits on a conforming implementation.   2.2.4.1 Translation limits     The implementation shall be able to translate and execute at least one program that contains at least one instance of every one of the following limits:/6/   * 15 nesting levels of compound statements, iteration control    structures, and selection control structures   * 8 nesting levels of conditional inclusion    * 12 pointer, array, and function declarators (in any combinations)    modifying an arithmetic, a structure, a union, or an incomplete type    in a declaration   * 31 declarators nested by parentheses within a full declarator    * 32 expressions nested by parentheses within a full expression    * 31 significant initial characters in an internal identifier or a    macro name   * 6 significant initial characters in an external identifier    * 511 external identifiers in one translation unit    * 127 identifiers with block scope declared in one block    * 1024 macro identifiers simultaneously defined in one translation unit    * 31 parameters in one function definition    * 31 arguments in one function call    * 31 parameters in one macro definition    * 31 arguments in one macro invocation    * 509 characters in a logical source line    * 509 characters in a character string literal or wide string literal    (after concatenation)   * 32767 bytes in an object (in a hosted environment only)    * 8 nesting levels for #include'd files    * 257 case labels for a switch statement (excluding those for any    nested switch statements)   * 127 members in a single structure or union    * 127 enumeration constants in a single enumeration    * 15 levels of nested structure or union definitions in a single    struct-declaration-list   2.2.4.2 Numerical limits     A conforming implementation shall document all the limits specified in this section, which shall be specified in the headers <limits.h> and <float.h> .  "Sizes of integral types <limits.h>"     The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives.  Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.   * maximum number of bits for smallest object that is not a bit-field (byte)  CHAR_BIT                         8    * minimum value for an object of type signed char  SCHAR_MIN                     -127    * maximum value for an object of type signed char  SCHAR_MAX                     +127    * maximum value for an object of type unsigned char  UCHAR_MAX                      255    * minimum value for an object of type char  CHAR_MIN                     see below    * maximum value for an object of type char  CHAR_MAX                     see below    * maximum number of bytes in a multibyte character, for any supported locale  MB_LEN_MAX                       1    * minimum value for an object of type short int  SHRT_MIN                    -32767    * maximum value for an object of type short int  SHRT_MAX                    +32767    * maximum value for an object of type unsigned short int  USHRT_MAX                    65535    * minimum value for an object of type int  INT_MIN                     -32767    * maximum value for an object of type int  INT_MAX                     +32767    * maximum value for an object of type unsigned int  UINT_MAX                     65535    * minimum value for an object of type long int  LONG_MIN               -2147483647    * maximum value for an object of type long int  LONG_MAX               +2147483647    * maximum value for an object of type unsigned long int  ULONG_MAX               4294967295     If the value of an object of type char sign-extends when used in an expression, the value of CHAR_MIN shall be the same as that of SCHAR_MIN and the value of CHAR_MAX shall be the same as that of SCHAR_MAX .  If the value of an object of type char does not sign-extend when used in an expression, the value of CHAR_MIN shall be 0 and the value of CHAR_MAX shall be the same as that of UCHAR_MAX ./7/  "Characteristics of floating types <float.h>"     delim $$ The characteristics of floating types are defined in terms of a model that describes a representation of floating-point numbers and values that provide information about an implementation's floating-point arithmetic.  The following parameters are used to define the model for each floating-point type:     A normalized floating-point number x ($f sub 1$ > 0 if x is defined by the following model:/8/ $x~=~s~times~b sup e~times~sum from k=1 to p~f sub k~times~b sup -k~,~~~e sub min~<=~e~<=~e sub max$     Of the values in the <float.h> header, FLT_RADIX shall be a constant expression suitable for use in #if preprocessing directives; all other values need not be constant expressions.  All except FLT_RADIX and FLT_ROUNDS have separate names for all three floating-point types.  The floating-point model representation is provided for all values except FLT_ROUNDS .     The rounding mode for floating-point addition is characterized by the value of FLT_ROUNDS : -1 indeterminable, 0 toward zero, 1 to nearest, 2 toward positive infinity, 3 toward negative infinity.  All other values for FLT_ROUNDS characterize implementation-defined rounding behavior.     The values given in the following list shall be replaced by implementation-defined expressions that shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.   * radix of exponent representation, b  FLT_RADIX                        2    * number of base- FLT_RADIX digits in the floating-point mantissa, p   FLT_MANT_DIG DBL_MANT_DIG LDBL_MANT_DIG     * number of decimal digits of precision, $left floor~(p~-~1)~times~{    log sub 10 } b~right floor ~+~ left { lpile { 1 above 0 } ~~ lpile {    roman "if " b roman " is a power of 10" above roman otherwise }$  FLT_DIG                          6 DBL_DIG                         10 LDBL_DIG                        10     * minimum negative integer such that FLT_RADIX raised to that power    minus 1 is a normalized floating-point number, $e sub min$  FLT_MIN_EXP DBL_MIN_EXP LDBL_MIN_EXP     * minimum negative integer such that 10 raised to that power is in    the range of normalized floating-point numbers,  FLT_MIN_10_EXP                 -37 DBL_MIN_10_EXP                 -37 LDBL_MIN_10_EXP                -37     * maximum integer such that FLT_RADIX raised to that power minus 1 is    a representable finite floating-point number, $e sub max$  FLT_MAX_EXP DBL_MAX_EXP LDBL_MAX_EXP     * maximum integer such that 10 raised to that power is in the range    of representable finite floating-point numbers,  FLT_MAX_10_EXP                 +37 DBL_MAX_10_EXP                 +37 LDBL_MAX_10_EXP                +37      The values given in the following list shall be replaced by implementation-defined expressions with values that shall be equal to or greater than those shown.   * maximum representable finite floating-point number,   FLT_MAX                      1E+37 DBL_MAX                      1E+37 LDBL_MAX                     1E+37      The values given in the following list shall be replaced by implementation-defined expressions with values that shall be equal to or smaller than those shown.   * minimum positive floating-point number x such that 1.0 + x   FLT_EPSILON                   1E-5 DBL_EPSILON                   1E-9 LDBL_EPSILON                  1E-9     * minimum normalized positive floating-point number, $b sup { e sub    min - 1 }$  FLT_MIN                      1E-37 DBL_MIN                      1E-37 LDBL_MIN                     1E-37    Examples     The following describes an artificial floating-point representation that meets the minimum requirements of the Standard, and the appropriate values in a <float.h> header for type float : $x~=~s~times~16 sup e~times~sum from k=1 to 6~f sub k~times~16 sup -k~,~~~-31~<=~e~<=~+32$               FLT_RADIX                       16          FLT_MANT_DIG                     6          FLT_EPSILON        9.53674316E-07F          FLT_DIG                          6          FLT_MIN_EXP                    -31          FLT_MIN            2.93873588E-39F          FLT_MIN_10_EXP                 -38          FLT_MAX_EXP                    +32          FLT_MAX            3.40282347E+38F          FLT_MAX_10_EXP                 +38      The following describes floating-point representations that also meet the requirements for single-precision and double-precision normalized numbers in the IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985),/9/ b and the appropriate values in a <float.h> header for types float and double : $x sub f~=~s~times~2 sup e~times~{ sum from k=1 to 24~f sub k~times~2 sup -k },~~~-125~<=~e~<=~+128$ $x sub d~=~s~times~2 sup e~times~{ sum from k=1 to 53~f sub k~times~2 sup -k },~~~-1021~<=~e~<=~+1024$               FLT_RADIX                        2          FLT_MANT_DIG                    24          FLT_EPSILON        1.19209290E-07F          FLT_DIG                          6          FLT_MIN_EXP                   -125          FLT_MIN            1.17549435E-38F          FLT_MIN_10_EXP                 -37          FLT_MAX_EXP                   +128          FLT_MAX            3.40282347E+38F          FLT_MAX_10_EXP                 +38          DBL_MANT_DIG                    53          DBL_EPSILON 2.2204460492503131E-16          DBL_DIG                         15          DBL_MIN_EXP                  -1021          DBL_MIN    2.2250738585072016E-308          DBL_MIN_10_EXP                -307          DBL_MAX_EXP                  +1024          DBL_MAX    1.7976931348623157E+308          DBL_MAX_10_EXP                +308      The values shown above for FLT_EPSILON and DBL_EPSILON are appropriate for the ANSI/IEEE Std 754-1985 default rounding mode (to nearest).  Their values may differ for other rounding modes.  Forward references: conditional inclusion ($3.8.1).  conditional inclusion ($3.8.1).   3. LANGUAGE     In the syntax notation used in the language section ($3), syntactic categories (nonterminals) are indicated by italic type, and literal words and character set members (terminals) by bold type.  A colon (:) following a nonterminal introduces its definition.  Alternative definitions are listed on separate lines, except when prefaced by the words ``one of.'' An optional symbol is indicated by the so that           {  expression<opt> }  indicates an optional expression enclosed in braces.    3.1 LEXICAL ELEMENTS   Syntax            token:                   keyword                   identifier                   constant                   string-literal                   operator                   punctuator            preprocessing-token:                   header-name                   identifier                   pp-number                   character-constant                   string-literal                   operator                   punctuator                   each non-white-space character that cannot be one of                   the above    Constraints     Each preprocessing token that is converted to a token shall have the lexical form of a keyword, an identifier, a constant, a string literal, an operator, or a punctuator.  Semantics     A token is the minimal lexical element of the language in translation phases 7 and 8.  The categories of tokens are: keywords, identifiers, constants, string literals, operators, and punctuators. A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6.  The categories of preprocessing token are: header names, identifiers, preprocessing numbers, character constants, string literals, operators, punctuators, and single non-white-space characters that do not lexically match the other preprocessing token categories.  If a ' or a " character matches the last category, the behavior is undefined.  Comments (described later) and the characters space, horizontal tab, new-line, vertical tab, and form-feed---collectively called white space ---canseparate preprocessing tokens.  As described in $3.8, in certain circumstances during translation phase 4, white space (or the absence thereof) serves as more than preprocessing token separation.  White space may appear within a preprocessing token only as part of a header name or between the quotation characters in a character constant or string literal.     If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token.  Examples     The program fragment 1Ex is parsed as a preprocessing number token (one that is not a valid floating or integer constant token), even though a parse as the pair of preprocessing tokens 1 and Ex might produce a valid expression (for example, if Ex were a macro defined as +1 ).  Similarly, the program fragment 1E1 is parsed as a preprocessing number (one that is a valid floating constant token), whether or not E is a macro name.     The program fragment x+++++y is parsed as x ++ ++ + y, which violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression.  Forward references: character constants ($3.1.3.4), comments ($3.1.9), expressions ($3.3), floating constants ($3.1.3.1), header names ($3.1.7), macro replacement ($3.8.3), postfix increment and decrement operators ($3.3.2.4), prefix increment and decrement operators ($3.3.3.1), preprocessing directives ($3.8), preprocessing numbers ($3.1.8), string literals ($3.1.4).   3.1.1 Keywords  Syntax           keyword: one of           auto     double   int      struct          break    else     long     switch          case     enum     register typedef          char     extern   return   union          const    float    short    unsigned          continue for      signed   void          defa