remove old c1x draft (n1548)
authornsz <nsz@port70.net>
Sun, 24 Jul 2011 12:05:47 +0000 (14:05 +0200)
committernsz <nsz@port70.net>
Sun, 24 Jul 2011 12:05:47 +0000 (14:05 +0200)
n1548.html [deleted file]
n1548.txt [deleted file]

diff --git a/n1548.html b/n1548.html
deleted file mode 100644 (file)
index 6502e1f..0000000
+++ /dev/null
@@ -1,34498 +0,0 @@
-<html><head><title>N1548   December 2, 2010  ISO/IEC 9899:201x</title></head><body>
-<pre><!--page 1 -->
-N1548                    Committee Draft -- December 2, 2010          ISO/IEC 9899:201x
-
-
-
-
-INTERNATIONAL STANDARD                         (C)ISO/IEC              ISO/IEC 9899:201x
-
-
-
-
-</pre>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h1>Programming languages -- C</h1>
-<pre>
-
-
-                                       ABSTRACT
-
-
-
-                     (Cover sheet to be provided by ISO Secretariat.)
-
-This International Standard specifies the form and establishes the interpretation of
-programs expressed in the programming language C. Its purpose is to promote
-portability, reliability, maintainability, and efficient execution of C language programs on
-a variety of computing systems.
-
-Clauses are included that detail the C language itself and the contents of the C language
-execution library. Annexes summarize aspects of both of them, and enumerate factors
-that influence the portability of C programs.
-
-Although this International Standard is intended to guide knowledgeable C language
-programmers as well as implementors of C language translation systems, the document
-itself is not designed to serve as a tutorial.
-
-Recipients of this draft are invited to submit, with their comments, notification of any
-relevant patent rights of which they are aware and to provide supporting documentation.
-
-Changes from the previous draft (N1256) are indicated by ''diff marks'' in the right
-margin: deleted text is marked with ''*'', new or changed text with '' ''.
-<!--page 2 -->
-<!--page 3 -->
-</pre>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="Contents" href="#Contents">Contents</a></h2>
-<ul>
-<li><a href="#Foreword">Foreword</a>
-<li><a href="#Introduction">Introduction</a>
-<li><a href="#1">1. Scope</a>
-<li><a href="#2">2. Normative references</a>
-<li><a href="#3">3. Terms, definitions, and symbols</a>
-<li><a href="#4">4. Conformance</a>
-<li><a href="#5">5. Environment</a>
-<ul>
-<li><a href="#5.1">   5.1 Conceptual models</a>
-<ul>
-<li><a href="#5.1.1">        5.1.1  Translation environment</a>
-<li><a href="#5.1.2">        5.1.2  Execution environments</a>
-</ul>
-<li><a href="#5.2">   5.2 Environmental considerations</a>
-<ul>
-<li><a href="#5.2.1">        5.2.1  Character sets</a>
-<li><a href="#5.2.2">        5.2.2  Character display semantics</a>
-<li><a href="#5.2.3">        5.2.3  Signals and interrupts</a>
-<li><a href="#5.2.4">        5.2.4  Environmental limits</a>
-</ul>
-</ul>
-<li><a href="#6">6. Language</a>
-<ul>
-<li><a href="#6.1">   6.1 Notation</a>
-<li><a href="#6.2">   6.2 Concepts</a>
-<ul>
-<li><a href="#6.2.1">        6.2.1   Scopes of identifiers</a>
-<li><a href="#6.2.2">        6.2.2   Linkages of identifiers</a>
-<li><a href="#6.2.3">        6.2.3   Name spaces of identifiers</a>
-<li><a href="#6.2.4">        6.2.4   Storage durations of objects</a>
-<li><a href="#6.2.5">        6.2.5   Types</a>
-<li><a href="#6.2.6">        6.2.6   Representations of types</a>
-<li><a href="#6.2.7">        6.2.7   Compatible type and composite type</a>
-<li><a href="#6.2.8">        6.2.8   Alignment of objects</a>
-</ul>
-<li><a href="#6.3">   6.3 Conversions</a>
-<ul>
-<li><a href="#6.3.1">        6.3.1   Arithmetic operands</a>
-<li><a href="#6.3.2">        6.3.2   Other operands</a>
-</ul>
-<li><a href="#6.4">   6.4 Lexical elements</a>
-<ul>
-<li><a href="#6.4.1">        6.4.1   Keywords</a>
-<li><a href="#6.4.2">        6.4.2   Identifiers</a>
-<li><a href="#6.4.3">        6.4.3   Universal character names</a>
-<li><a href="#6.4.4">        6.4.4   Constants</a>
-<li><a href="#6.4.5">        6.4.5   String literals</a>
-<li><a href="#6.4.6">        6.4.6   Punctuators</a>
-<li><a href="#6.4.7">        6.4.7   Header names</a>
-<li><a href="#6.4.8">        6.4.8   Preprocessing numbers</a>
-<li><a href="#6.4.9">        6.4.9   Comments</a>
-<!--page 4 -->
-</ul>
-<li><a href="#6.5">     6.5  Expressions</a>
-<ul>
-<li><a href="#6.5.1">          6.5.1   Primary expressions</a>
-<li><a href="#6.5.2">          6.5.2   Postfix operators</a>
-<li><a href="#6.5.3">          6.5.3   Unary operators</a>
-<li><a href="#6.5.4">          6.5.4   Cast operators</a>
-<li><a href="#6.5.5">          6.5.5   Multiplicative operators</a>
-<li><a href="#6.5.6">          6.5.6   Additive operators</a>
-<li><a href="#6.5.7">          6.5.7   Bitwise shift operators</a>
-<li><a href="#6.5.8">          6.5.8   Relational operators</a>
-<li><a href="#6.5.9">          6.5.9   Equality operators</a>
-<li><a href="#6.5.10">          6.5.10 Bitwise AND operator</a>
-<li><a href="#6.5.11">          6.5.11 Bitwise exclusive OR operator</a>
-<li><a href="#6.5.12">          6.5.12 Bitwise inclusive OR operator</a>
-<li><a href="#6.5.13">          6.5.13 Logical AND operator</a>
-<li><a href="#6.5.14">          6.5.14 Logical OR operator</a>
-<li><a href="#6.5.15">          6.5.15 Conditional operator</a>
-<li><a href="#6.5.16">          6.5.16 Assignment operators</a>
-<li><a href="#6.5.17">          6.5.17 Comma operator</a>
-</ul>
-<li><a href="#6.6">     6.6 Constant expressions</a>
-<li><a href="#6.7">     6.7 Declarations</a>
-<ul>
-<li><a href="#6.7.1">          6.7.1   Storage-class specifiers</a>
-<li><a href="#6.7.2">          6.7.2   Type specifiers</a>
-<li><a href="#6.7.3">          6.7.3   Type qualifiers</a>
-<li><a href="#6.7.4">          6.7.4   Function specifiers</a>
-<li><a href="#6.7.5">          6.7.5   Alignment specifier</a>
-<li><a href="#6.7.6">          6.7.6   Declarators</a>
-<li><a href="#6.7.7">          6.7.7   Type names</a>
-<li><a href="#6.7.8">          6.7.8   Type definitions</a>
-<li><a href="#6.7.9">          6.7.9   Initialization</a>
-<li><a href="#6.7.10">          6.7.10 Static assertions</a>
-</ul>
-<li><a href="#6.8">     6.8 Statements and blocks</a>
-<ul>
-<li><a href="#6.8.1">          6.8.1   Labeled statements</a>
-<li><a href="#6.8.2">          6.8.2   Compound statement</a>
-<li><a href="#6.8.3">          6.8.3   Expression and null statements</a>
-<li><a href="#6.8.4">          6.8.4   Selection statements</a>
-<li><a href="#6.8.5">          6.8.5   Iteration statements</a>
-<li><a href="#6.8.6">          6.8.6   Jump statements</a>
-</ul>
-<li><a href="#6.9">     6.9 External definitions</a>
-<ul>
-<li><a href="#6.9.1">          6.9.1   Function definitions</a>
-<li><a href="#6.9.2">          6.9.2   External object definitions</a>
-</ul>
-<li><a href="#6.10">     6.10 Preprocessing directives</a>
-<ul>
-<li><a href="#6.10.1">          6.10.1 Conditional inclusion</a>
-<li><a href="#6.10.2">          6.10.2 Source file inclusion</a>
-<li><a href="#6.10.3">          6.10.3 Macro replacement</a>
-<!--page 5 -->
-<li><a href="#6.10.4">       6.10.4 Line control</a>
-<li><a href="#6.10.5">       6.10.5 Error directive</a>
-<li><a href="#6.10.6">       6.10.6 Pragma directive</a>
-<li><a href="#6.10.7">       6.10.7 Null directive</a>
-<li><a href="#6.10.8">       6.10.8 Predefined macro names</a>
-<li><a href="#6.10.9">       6.10.9 Pragma operator</a>
-</ul>
-<li><a href="#6.11">  6.11 Future language directions</a>
-<ul>
-<li><a href="#6.11.1">       6.11.1 Floating types</a>
-<li><a href="#6.11.2">       6.11.2 Linkages of identifiers</a>
-<li><a href="#6.11.3">       6.11.3 External names</a>
-<li><a href="#6.11.4">       6.11.4 Character escape sequences</a>
-<li><a href="#6.11.5">       6.11.5 Storage-class specifiers</a>
-<li><a href="#6.11.6">       6.11.6 Function declarators</a>
-<li><a href="#6.11.7">       6.11.7 Function definitions</a>
-<li><a href="#6.11.8">       6.11.8 Pragma directives</a>
-<li><a href="#6.11.9">       6.11.9 Predefined macro names</a>
-</ul>
-</ul>
-<li><a href="#7">7. Library</a>
-<ul>
-<li><a href="#7.1">   7.1 Introduction</a>
-<ul>
-<li><a href="#7.1.1">         7.1.1 Definitions of terms</a>
-<li><a href="#7.1.2">         7.1.2 Standard headers</a>
-<li><a href="#7.1.3">         7.1.3 Reserved identifiers</a>
-<li><a href="#7.1.4">         7.1.4 Use of library functions</a>
-</ul>
-<li><a href="#7.2">   7.2 Diagnostics &lt;assert.h&gt;</a>
-<ul>
-<li><a href="#7.2.1">         7.2.1 Program diagnostics</a>
-</ul>
-<li><a href="#7.3">   7.3 Complex arithmetic &lt;complex.h&gt;</a>
-<ul>
-<li><a href="#7.3.1">         7.3.1 Introduction</a>
-<li><a href="#7.3.2">         7.3.2 Conventions</a>
-<li><a href="#7.3.3">         7.3.3 Branch cuts</a>
-<li><a href="#7.3.4">         7.3.4 The CX_LIMITED_RANGE pragma</a>
-<li><a href="#7.3.5">         7.3.5 Trigonometric functions</a>
-<li><a href="#7.3.6">         7.3.6 Hyperbolic functions</a>
-<li><a href="#7.3.7">         7.3.7 Exponential and logarithmic functions</a>
-<li><a href="#7.3.8">         7.3.8 Power and absolute-value functions</a>
-<li><a href="#7.3.9">         7.3.9 Manipulation functions</a>
-</ul>
-<li><a href="#7.4">   7.4 Character handling &lt;ctype.h&gt;</a>
-<ul>
-<li><a href="#7.4.1">         7.4.1 Character classification functions</a>
-<li><a href="#7.4.2">         7.4.2 Character case mapping functions</a>
-</ul>
-<li><a href="#7.5">   7.5 Errors &lt;errno.h&gt;</a>
-<li><a href="#7.6">   7.6 Floating-point environment &lt;fenv.h&gt;</a>
-<ul>
-<li><a href="#7.6.1">         7.6.1 The FENV_ACCESS pragma</a>
-<li><a href="#7.6.2">         7.6.2 Floating-point exceptions</a>
-<li><a href="#7.6.3">         7.6.3 Rounding</a>
-<li><a href="#7.6.4">         7.6.4 Environment</a>
-</ul>
-<li><a href="#7.7">   7.7 Characteristics of floating types &lt;float.h&gt;</a>
-<!--page 6 -->
-<li><a href="#7.8">     7.8    Format conversion of integer types &lt;inttypes.h&gt;</a>
-<ul>
-<li><a href="#7.8.1">            7.8.1    Macros for format specifiers</a>
-<li><a href="#7.8.2">            7.8.2    Functions for greatest-width integer types</a>
-</ul>
-<li><a href="#7.9">     7.9    Alternative spellings &lt;iso646.h&gt;</a>
-<li><a href="#7.10">     7.10   Sizes of integer types &lt;limits.h&gt;</a>
-<li><a href="#7.11">     7.11   Localization &lt;locale.h&gt;</a>
-<ul>
-<li><a href="#7.11.1">            7.11.1 Locale control</a>
-<li><a href="#7.11.2">            7.11.2 Numeric formatting convention inquiry</a>
-</ul>
-<li><a href="#7.12">     7.12   Mathematics &lt;math.h&gt;</a>
-<ul>
-<li><a href="#7.12.1">            7.12.1 Treatment of error conditions</a>
-<li><a href="#7.12.2">            7.12.2 The FP_CONTRACT pragma</a>
-<li><a href="#7.12.3">            7.12.3 Classification macros</a>
-<li><a href="#7.12.4">            7.12.4 Trigonometric functions</a>
-<li><a href="#7.12.5">            7.12.5 Hyperbolic functions</a>
-<li><a href="#7.12.6">            7.12.6 Exponential and logarithmic functions</a>
-<li><a href="#7.12.7">            7.12.7 Power and absolute-value functions</a>
-<li><a href="#7.12.8">            7.12.8 Error and gamma functions</a>
-<li><a href="#7.12.9">            7.12.9 Nearest integer functions</a>
-<li><a href="#7.12.10">            7.12.10 Remainder functions</a>
-<li><a href="#7.12.11">            7.12.11 Manipulation functions</a>
-<li><a href="#7.12.12">            7.12.12 Maximum, minimum, and positive difference functions</a>
-<li><a href="#7.12.13">            7.12.13 Floating multiply-add</a>
-<li><a href="#7.12.14">            7.12.14 Comparison macros</a>
-</ul>
-<li><a href="#7.13">     7.13   Nonlocal jumps &lt;setjmp.h&gt;</a>
-<ul>
-<li><a href="#7.13.1">            7.13.1 Save calling environment</a>
-<li><a href="#7.13.2">            7.13.2 Restore calling environment</a>
-</ul>
-<li><a href="#7.14">     7.14   Signal handling &lt;signal.h&gt;</a>
-<ul>
-<li><a href="#7.14.1">            7.14.1 Specify signal handling</a>
-<li><a href="#7.14.2">            7.14.2 Send signal</a>
-</ul>
-<li><a href="#7.15">     7.15   Alignment &lt;stdalign.h&gt;</a>
-<li><a href="#7.16">     7.16   Variable arguments &lt;stdarg.h&gt;</a>
-<ul>
-<li><a href="#7.16.1">            7.16.1 Variable argument list access macros</a>
-</ul>
-<li><a href="#7.17">     7.17   Atomics &lt;stdatomic.h&gt;</a>
-<ul>
-<li><a href="#7.17.1">            7.17.1 Introduction</a>
-<li><a href="#7.17.2">            7.17.2 Initialization</a>
-<li><a href="#7.17.3">            7.17.3 Order and consistency</a>
-<li><a href="#7.17.4">            7.17.4 Fences</a>
-<li><a href="#7.17.5">            7.17.5 Lock-free property</a>
-<li><a href="#7.17.6">            7.17.6 Atomic integer and address types</a>
-<li><a href="#7.17.7">            7.17.7 Operations on atomic types</a>
-<li><a href="#7.17.8">            7.17.8 Atomic flag type and operations</a>
-</ul>
-<li><a href="#7.18">     7.18   Boolean type and values &lt;stdbool.h&gt;</a>
-<li><a href="#7.19">     7.19   Common definitions &lt;stddef.h&gt;</a>
-<li><a href="#7.20">     7.20   Integer types &lt;stdint.h&gt;</a>
-<!--page 7 -->
-<ul>
-<li><a href="#7.20.1">         7.20.1 Integer types</a>
-<li><a href="#7.20.2">         7.20.2 Limits of specified-width integer types</a>
-<li><a href="#7.20.3">         7.20.3 Limits of other integer types</a>
-<li><a href="#7.20.4">         7.20.4 Macros for integer constants</a>
-</ul>
-<li><a href="#7.21">  7.21   Input/output &lt;stdio.h&gt;</a>
-<ul>
-<li><a href="#7.21.1">         7.21.1 Introduction</a>
-<li><a href="#7.21.2">         7.21.2 Streams</a>
-<li><a href="#7.21.3">         7.21.3 Files</a>
-<li><a href="#7.21.4">         7.21.4 Operations on files</a>
-<li><a href="#7.21.5">         7.21.5 File access functions</a>
-<li><a href="#7.21.6">         7.21.6 Formatted input/output functions</a>
-<li><a href="#7.21.7">         7.21.7 Character input/output functions</a>
-<li><a href="#7.21.8">         7.21.8 Direct input/output functions</a>
-<li><a href="#7.21.9">         7.21.9 File positioning functions</a>
-<li><a href="#7.21.10">         7.21.10 Error-handling functions</a>
-</ul>
-<li><a href="#7.22">  7.22   General utilities &lt;stdlib.h&gt;</a>
-<ul>
-<li><a href="#7.22.1">         7.22.1 Numeric conversion functions</a>
-<li><a href="#7.22.2">         7.22.2 Pseudo-random sequence generation functions</a>
-<li><a href="#7.22.3">         7.22.3 Memory management functions</a>
-<li><a href="#7.22.4">         7.22.4 Communication with the environment</a>
-<li><a href="#7.22.5">         7.22.5 Searching and sorting utilities</a>
-<li><a href="#7.22.6">         7.22.6 Integer arithmetic functions</a>
-<li><a href="#7.22.7">         7.22.7 Multibyte/wide character conversion functions</a>
-<li><a href="#7.22.8">         7.22.8 Multibyte/wide string conversion functions</a>
-</ul>
-<li><a href="#7.23">  7.23   String handling &lt;string.h&gt;</a>
-<ul>
-<li><a href="#7.23.1">         7.23.1 String function conventions</a>
-<li><a href="#7.23.2">         7.23.2 Copying functions</a>
-<li><a href="#7.23.3">         7.23.3 Concatenation functions</a>
-<li><a href="#7.23.4">         7.23.4 Comparison functions</a>
-<li><a href="#7.23.5">         7.23.5 Search functions</a>
-<li><a href="#7.23.6">         7.23.6 Miscellaneous functions</a>
-</ul>
-<li><a href="#7.24">  7.24   Type-generic math &lt;tgmath.h&gt;</a>
-<li><a href="#7.25">  7.25   Threads &lt;threads.h&gt;</a>
-<ul>
-<li><a href="#7.25.1">         7.25.1 Introduction</a>
-<li><a href="#7.25.2">         7.25.2 Initialization functions</a>
-<li><a href="#7.25.3">         7.25.3 Condition variable functions</a>
-<li><a href="#7.25.4">         7.25.4 Mutex functions</a>
-<li><a href="#7.25.5">         7.25.5 Thread functions</a>
-<li><a href="#7.25.6">         7.25.6 Thread-specific storage functions</a>
-<li><a href="#7.25.7">         7.25.7 Time functions</a>
-</ul>
-<li><a href="#7.26">  7.26   Date and time &lt;time.h&gt;</a>
-<ul>
-<li><a href="#7.26.1">         7.26.1 Components of time</a>
-<li><a href="#7.26.2">         7.26.2 Time manipulation functions</a>
-<li><a href="#7.26.3">         7.26.3 Time conversion functions</a>
-<!--page 8 -->
-</ul>
-<li><a href="#7.27">   7.27 Unicode utilities &lt;uchar.h&gt;</a>
-<ul>
-<li><a href="#7.27.1">        7.27.1 Restartable multibyte/wide character conversion functions</a>
-</ul>
-<li><a href="#7.28">   7.28 Extended multibyte and wide character utilities &lt;wchar.h&gt;</a>
-<ul>
-<li><a href="#7.28.1">        7.28.1 Introduction</a>
-<li><a href="#7.28.2">        7.28.2 Formatted wide character input/output functions</a>
-<li><a href="#7.28.3">        7.28.3 Wide character input/output functions</a>
-<li><a href="#7.28.4">        7.28.4 General wide string utilities</a>
-<ul>
-<li><a href="#7.28.4.1">                 7.28.4.1 Wide string numeric conversion functions</a>
-<li><a href="#7.28.4.2">                 7.28.4.2 Wide string copying functions</a>
-<li><a href="#7.28.4.3">                 7.28.4.3 Wide string concatenation functions</a>
-<li><a href="#7.28.4.4">                 7.28.4.4 Wide string comparison functions</a>
-<li><a href="#7.28.4.5">                 7.28.4.5 Wide string search functions</a>
-<li><a href="#7.28.4.6">                 7.28.4.6 Miscellaneous functions</a>
-</ul>
-<li><a href="#7.28.5">        7.28.5 Wide character time conversion functions</a>
-<li><a href="#7.28.6">        7.28.6 Extended multibyte/wide character conversion utilities</a>
-<ul>
-<li><a href="#7.28.6.1">                 7.28.6.1 Single-byte/wide character conversion functions</a>
-<li><a href="#7.28.6.2">                 7.28.6.2 Conversion state functions</a>
-<li><a href="#7.28.6.3">                 7.28.6.3 Restartable multibyte/wide character conversion functions</a>
-<li><a href="#7.28.6.4">                 7.28.6.4 Restartable multibyte/wide string conversion functions</a>
-</ul>
-</ul>
-<li><a href="#7.29">   7.29 Wide character classification and mapping utilities &lt;wctype.h&gt;</a>
-<ul>
-<li><a href="#7.29.1">        7.29.1 Introduction</a>
-<li><a href="#7.29.2">        7.29.2 Wide character classification utilities</a>
-<ul>
-<li><a href="#7.29.2.1">                 7.29.2.1 Wide character classification functions</a>
-<li><a href="#7.29.2.2">                 7.29.2.2 Extensible wide character classification functions</a>
-</ul>
-<li><a href="#7.29.3">        7.29.3 Wide character case mapping utilities</a>
-<ul>
-<li><a href="#7.29.3.1">                 7.29.3.1 Wide character case mapping functions</a>
-<li><a href="#7.29.3.2">                 7.29.3.2 Extensible wide character case mapping functions</a>
-</ul>
-</ul>
-<li><a href="#7.30">   7.30 Future library directions</a>
-<ul>
-<li><a href="#7.30.1">        7.30.1 Complex arithmetic &lt;complex.h&gt;</a>
-<li><a href="#7.30.2">        7.30.2 Character handling &lt;ctype.h&gt;</a>
-<li><a href="#7.30.3">        7.30.3 Errors &lt;errno.h&gt;</a>
-<li><a href="#7.30.4">        7.30.4 Format conversion of integer types &lt;inttypes.h&gt;</a>
-<li><a href="#7.30.5">        7.30.5 Localization &lt;locale.h&gt;</a>
-<li><a href="#7.30.6">        7.30.6 Signal handling &lt;signal.h&gt;</a>
-<li><a href="#7.30.7">        7.30.7 Boolean type and values &lt;stdbool.h&gt;</a>
-<li><a href="#7.30.8">        7.30.8 Integer types &lt;stdint.h&gt;</a>
-<li><a href="#7.30.9">        7.30.9 Input/output &lt;stdio.h&gt;</a>
-<li><a href="#7.30.10">        7.30.10 General utilities &lt;stdlib.h&gt;</a>
-<li><a href="#7.30.11">        7.30.11 String handling &lt;string.h&gt;</a>
-<!--page 9 -->
-<li><a href="#7.30.12">        7.30.12 Extended multibyte and wide character utilities &lt;wchar.h&gt;</a>
-<li><a href="#7.30.13">        7.30.13 Wide character classification and mapping utilities &lt;wctype.h&gt;</a>
-</ul>
-</ul>
-<li><a href="#A">Annex A (informative) Language syntax summary</a>
-<ul>
-<li><a href="#A.1">  A.1 Lexical grammar</a>
-<li><a href="#A.2">  A.2 Phrase structure grammar</a>
-<li><a href="#A.3">  A.3 Preprocessing directives</a>
-</ul>
-<li><a href="#B">Annex B (informative) Library summary</a>
-<ul>
-<li><a href="#B.1">  B.1 Diagnostics &lt;assert.h&gt;</a>
-<li><a href="#B.2">  B.2 Complex &lt;complex.h&gt;</a>
-<li><a href="#B.3">  B.3 Character handling &lt;ctype.h&gt;</a>
-<li><a href="#B.4">  B.4 Errors &lt;errno.h&gt;</a>
-<li><a href="#B.5">  B.5 Floating-point environment &lt;fenv.h&gt;</a>
-<li><a href="#B.6">  B.6 Characteristics of floating types &lt;float.h&gt;</a>
-<li><a href="#B.7">  B.7 Format conversion of integer types &lt;inttypes.h&gt;</a>
-<li><a href="#B.8">  B.8 Alternative spellings &lt;iso646.h&gt;</a>
-<li><a href="#B.9">  B.9 Sizes of integer types &lt;limits.h&gt;</a>
-<li><a href="#B.10">  B.10 Localization &lt;locale.h&gt;</a>
-<li><a href="#B.11">  B.11 Mathematics &lt;math.h&gt;</a>
-<li><a href="#B.12">  B.12 Nonlocal jumps &lt;setjmp.h&gt;</a>
-<li><a href="#B.13">  B.13 Signal handling &lt;signal.h&gt;</a>
-<li><a href="#B.14">  B.14 Alignment &lt;stdalign.h&gt;</a>
-<li><a href="#B.15">  B.15 Variable arguments &lt;stdarg.h&gt;</a>
-<li><a href="#B.16">  B.16 Atomics &lt;stdatomic.h&gt;</a>
-<li><a href="#B.17">  B.17 Boolean type and values &lt;stdbool.h&gt;</a>
-<li><a href="#B.18">  B.18 Common definitions &lt;stddef.h&gt;</a>
-<li><a href="#B.19">  B.19 Integer types &lt;stdint.h&gt;</a>
-<li><a href="#B.20">  B.20 Input/output &lt;stdio.h&gt;</a>
-<li><a href="#B.21">  B.21 General utilities &lt;stdlib.h&gt;</a>
-<li><a href="#B.22">  B.22 String handling &lt;string.h&gt;</a>
-<li><a href="#B.23">  B.23 Type-generic math &lt;tgmath.h&gt;</a>
-<li><a href="#B.24">  B.24 Threads &lt;threads.h&gt;</a>
-<li><a href="#B.25">  B.25 Date and time &lt;time.h&gt;</a>
-<li><a href="#B.26">  B.26 Unicode utilities &lt;uchar.h&gt;</a>
-<li><a href="#B.27">  B.27 Extended multibyte/wide character utilities &lt;wchar.h&gt;</a>
-<li><a href="#B.28">  B.28 Wide character classification and mapping utilities &lt;wctype.h&gt;</a>
-</ul>
-<li><a href="#C">Annex C (informative) Sequence points</a>
-<li><a href="#D">Annex D (normative) Universal character names for identifiers</a>
-<ul>
-<li><a href="#D.1">  D.1 Ranges of characters allowed</a>
-<li><a href="#D.2">  D.2 Ranges of characters disallowed initially</a>
-</ul>
-<li><a href="#E">Annex E (informative) Implementation limits</a>
-<!--page 10 -->
-<li><a href="#F">Annex F (normative) IEC 60559 floating-point arithmetic</a>
-<ul>
-<li><a href="#F.1">  F.1 Introduction</a>
-<li><a href="#F.2">  F.2 Types</a>
-<li><a href="#F.3">  F.3 Operators and functions</a>
-<li><a href="#F.4">  F.4 Floating to integer conversion</a>
-<li><a href="#F.5">  F.5 Binary-decimal conversion</a>
-<li><a href="#F.6">  F.6 The return statement</a>
-<li><a href="#F.7">  F.7 Contracted expressions</a>
-<li><a href="#F.8">  F.8 Floating-point environment</a>
-<li><a href="#F.9">  F.9 Optimization</a>
-<li><a href="#F.10">  F.10 Mathematics &lt;math.h&gt;</a>
-<ul>
-<li><a href="#F.10.1">        F.10.1 Trigonometric functions</a>
-<li><a href="#F.10.2">        F.10.2 Hyperbolic functions</a>
-<li><a href="#F.10.3">        F.10.3 Exponential and logarithmic functions</a>
-<li><a href="#F.10.4">        F.10.4 Power and absolute value functions</a>
-<li><a href="#F.10.5">        F.10.5 Error and gamma functions</a>
-<li><a href="#F.10.6">        F.10.6 Nearest integer functions</a>
-<li><a href="#F.10.7">        F.10.7 Remainder functions</a>
-<li><a href="#F.10.8">        F.10.8 Manipulation functions</a>
-<li><a href="#F.10.9">        F.10.9 Maximum, minimum, and positive difference functions</a>
-<li><a href="#F.10.10">        F.10.10 Floating multiply-add</a>
-<li><a href="#F.10.11">        F.10.11 Comparison macros</a>
-</ul>
-</ul>
-<li><a href="#G">Annex G (normative) IEC 60559-compatible complex arithmetic</a>
-<ul>
-<li><a href="#G.1">  G.1 Introduction</a>
-<li><a href="#G.2">  G.2 Types</a>
-<li><a href="#G.3">  G.3 Conventions</a>
-<li><a href="#G.4">  G.4 Conversions</a>
-<ul>
-<li><a href="#G.4.1">       G.4.1 Imaginary types</a>
-<li><a href="#G.4.2">       G.4.2 Real and imaginary</a>
-<li><a href="#G.4.3">       G.4.3 Imaginary and complex</a>
-</ul>
-<li><a href="#G.5">  G.5 Binary operators</a>
-<ul>
-<li><a href="#G.5.1">       G.5.1 Multiplicative operators</a>
-<li><a href="#G.5.2">       G.5.2 Additive operators</a>
-</ul>
-<li><a href="#G.6">  G.6 Complex arithmetic &lt;complex.h&gt;</a>
-<ul>
-<li><a href="#G.6.1">       G.6.1 Trigonometric functions</a>
-<li><a href="#G.6.2">       G.6.2 Hyperbolic functions</a>
-<li><a href="#G.6.3">       G.6.3 Exponential and logarithmic functions</a>
-<li><a href="#G.6.4">       G.6.4 Power and absolute-value functions</a>
-</ul>
-<li><a href="#G.7">  G.7 Type-generic math &lt;tgmath.h&gt;</a>
-</ul>
-<li><a href="#H">Annex H (informative) Language independent arithmetic</a>
-<ul>
-<li><a href="#H.1">  H.1 Introduction</a>
-<li><a href="#H.2">  H.2 Types</a>
-<li><a href="#H.3">  H.3 Notification</a>
-<!--page 11 -->
-</ul>
-<li><a href="#I">Annex I (informative) Common warnings</a>
-<li><a href="#J">Annex J (informative) Portability issues</a>
-<ul>
-<li><a href="#J.1">  J.1 Unspecified behavior</a>
-<li><a href="#J.2">  J.2 Undefined behavior</a>
-<li><a href="#J.3">  J.3 Implementation-defined behavior</a>
-<li><a href="#J.4">  J.4 Locale-specific behavior</a>
-<li><a href="#J.5">  J.5 Common extensions</a>
-</ul>
-<li><a href="#K">Annex K (normative) Bounds-checking interfaces</a>
-<ul>
-<li><a href="#K.1">  K.1 Background</a>
-<li><a href="#K.2">  K.2 Scope</a>
-<li><a href="#K.3">  K.3 Library</a>
-<ul>
-<li><a href="#K.3.1">       K.3.1 Introduction</a>
-<ul>
-<li><a href="#K.3.1.1">                K.3.1.1 Standard headers</a>
-<li><a href="#K.3.1.2">                K.3.1.2 Reserved identifiers</a>
-<li><a href="#K.3.1.3">                K.3.1.3 Use of errno</a>
-<li><a href="#K.3.1.4">                K.3.1.4 Runtime-constraint violations</a>
-</ul>
-<li><a href="#K.3.2">       K.3.2 Errors &lt;errno.h&gt;</a>
-<li><a href="#K.3.3">       K.3.3 Common definitions &lt;stddef.h&gt;</a>
-<li><a href="#K.3.4">       K.3.4 Integer types &lt;stdint.h&gt;</a>
-<li><a href="#K.3.5">       K.3.5 Input/output &lt;stdio.h&gt;</a>
-<ul>
-<li><a href="#K.3.5.1">                K.3.5.1 Operations on files</a>
-<li><a href="#K.3.5.2">                K.3.5.2 File access functions</a>
-<li><a href="#K.3.5.3">                K.3.5.3 Formatted input/output functions</a>
-<li><a href="#K.3.5.4">                K.3.5.4 Character input/output functions</a>
-</ul>
-<li><a href="#K.3.6">       K.3.6 General utilities &lt;stdlib.h&gt;</a>
-<ul>
-<li><a href="#K.3.6.1">                K.3.6.1 Runtime-constraint handling</a>
-<li><a href="#K.3.6.2">                K.3.6.2 Communication with the environment</a>
-<li><a href="#K.3.6.3">                K.3.6.3 Searching and sorting utilities</a>
-<li><a href="#K.3.6.4">                K.3.6.4 Multibyte/wide character conversion functions</a>
-<li><a href="#K.3.6.5">                K.3.6.5 Multibyte/wide string conversion functions</a>
-</ul>
-<li><a href="#K.3.7">       K.3.7 String handling &lt;string.h&gt;</a>
-<ul>
-<li><a href="#K.3.7.1">                K.3.7.1 Copying functions</a>
-<li><a href="#K.3.7.2">                K.3.7.2 Concatenation functions</a>
-<li><a href="#K.3.7.3">                K.3.7.3 Search functions</a>
-<li><a href="#K.3.7.4">                K.3.7.4 Miscellaneous functions</a>
-</ul>
-<li><a href="#K.3.8">       K.3.8 Date and time &lt;time.h&gt;</a>
-<ul>
-<li><a href="#K.3.8.1">                K.3.8.1 Components of time</a>
-<li><a href="#K.3.8.2">                K.3.8.2 Time conversion functions</a>
-</ul>
-<li><a href="#K.3.9">       K.3.9 Extended multibyte and wide character utilities &lt;wchar.h&gt;</a>
-<ul>
-<li><a href="#K.3.9.1">                K.3.9.1 Formatted wide character input/output functions</a>
-<li><a href="#K.3.9.2">                K.3.9.2 General wide string utilities</a>
-<!--page 12 -->
-<li><a href="#K.3.9.3">               K.3.9.3 Extended multibyte/wide character conversion utilities</a>
-</ul>
-</ul>
-</ul>
-<li><a href="#L">Annex L (normative) Analyzability</a>
-<ul>
-<li><a href="#L.1">  L.1 Scope</a>
-<li><a href="#L.2">  L.2 Definitions</a>
-<li><a href="#L.3">  L.3 Requirements</a>
-</ul>
-<li><a href="#Bibliography">Bibliography</a>
-<li><a href="#Index">Index</a>
-<!--page 13 -->
-</ul>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="Foreword" href="#Foreword">Foreword</a></h2>
-<p><!--para 1 -->
- ISO (the International Organization for Standardization) and IEC (the International
- Electrotechnical Commission) form the specialized system for worldwide
- standardization. National bodies that are member of ISO or IEC participate in the
- development of International Standards through technical committees established by the
- respective organization to deal with particular fields of technical activity. ISO and IEC
- technical committees collaborate in fields of mutual interest. Other international
- organizations, governmental and non-governmental, in liaison with ISO and IEC, also
- take part in the work.
-<p><!--para 2 -->
- International Standards are drafted in accordance with the rules given in the ISO/IEC
- Directives, Part 2. This International Standard was drafted in accordance with the fifth
- edition (2004).
-<p><!--para 3 -->
- In the field of information technology, ISO and IEC have established a joint technical
- committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical
- committee are circulated to national bodies for voting. Publication as an International
- Standard requires approval by at least 75% of the national bodies casting a vote.
-<p><!--para 4 -->
- Attention is drawn to the possibility that some of the elements of this document may be
- the subject of patent rights. ISO and IEC shall not be held responsible for identifying any
- or all such patent rights.
-<p><!--para 5 -->
- This International Standard was prepared by Joint Technical Committee ISO/IEC JTC 1,
- Information technology, Subcommittee SC 22, Programming languages, their
- environments and system software interfaces. The Working Group responsible for this
- standard (WG 14) maintains a site on the World Wide Web at http://www.open-
- std.org/JTC1/SC22/WG14/ containing additional information relevant to this
- standard such as a Rationale for many of the decisions made during its preparation and a
- log of Defect Reports and Responses.
-<p><!--para 6 -->
- This third edition cancels and replaces the second edition, ISO/IEC 9899:1999, as
- corrected by ISO/IEC 9899:1999/Cor 1:2001, ISO/IEC 9899:1999/Cor 2:2004, and
- ISO/IEC 9899:1999/Cor 3:2007. Major changes from the previous edition include:
-<ul>
-<li>  conditional (optional) features (including some that were previously mandatory)
-<li>  support for multiple threads of execution including an improved memory sequencing
- model, atomic objects, and thread-local storage (<a href="#7.17">&lt;stdatomic.h&gt;</a> and
- <a href="#7.25">&lt;threads.h&gt;</a>)
-<li>  additional floating-point characteristic macros (<a href="#7.7">&lt;float.h&gt;</a>)
-<li>  querying and specifying alignment of objects (<a href="#7.15">&lt;stdalign.h&gt;</a>, <a href="#7.22">&lt;stdlib.h&gt;</a>)
-<li>  Unicode characters and           strings   (<a href="#7.27">&lt;uchar.h&gt;</a>)       (originally   specified    in
- ISO/IEC TR 19769:2004)
-<li>  type-generic expressions
-<!--page 14 -->
-<li>  static assertions
-<li>  anonymous structures and unions
-<li>  no-return functions
-<li>  macros to create complex numbers (<a href="#7.3">&lt;complex.h&gt;</a>)
-<li>  support for opening files for exclusive access
-<li>  removed the gets function (<a href="#7.21">&lt;stdio.h&gt;</a>)
-<li>  added the aligned_alloc, at_quick_exit, and quick_exit functions
- (<a href="#7.22">&lt;stdlib.h&gt;</a>)
-<li>  (conditional) support for bounds-checking interfaces (originally specified in
- ISO/IEC TR 24731-1:2007)
-<li>  (conditional) support for analyzability
-</ul>
-<p><!--para 7 -->
- Major changes in the second edition included:
-<ul>
-<li>  restricted character set support via digraphs and <a href="#7.9">&lt;iso646.h&gt;</a> (originally specified
- in AMD1)
-<li>  wide character library support in <a href="#7.28">&lt;wchar.h&gt;</a> and <a href="#7.29">&lt;wctype.h&gt;</a> (originally
- specified in AMD1)
-<li>  more precise aliasing rules via effective type
-<li>  restricted pointers
-<li>  variable length arrays
-<li>  flexible array members
-<li>  static and type qualifiers in parameter array declarators
-<li>  complex (and imaginary) support in <a href="#7.3">&lt;complex.h&gt;</a>
-<li>  type-generic math macros in <a href="#7.24">&lt;tgmath.h&gt;</a>
-<li>  the long long int type and library functions
-<li>  increased minimum translation limits
-<li>  additional floating-point characteristics in <a href="#7.7">&lt;float.h&gt;</a>
-<li>  remove implicit int
-<li>  reliable integer division
-<li>  universal character names (\u and \U)
-<li>  extended identifiers
-<li>  hexadecimal floating-point constants and %a and %A printf/scanf conversion
- specifiers
-<!--page 15 -->
-<li>  compound literals
-<li>  designated initializers
-<li>  // comments
-<li>  extended integer types and library functions in <a href="#7.8">&lt;inttypes.h&gt;</a> and <a href="#7.20">&lt;stdint.h&gt;</a>
-<li>  remove implicit function declaration
-<li>  preprocessor arithmetic done in intmax_t/uintmax_t
-<li>  mixed declarations and code
-<li>  new block scopes for selection and iteration statements
-<li>  integer constant type rules
-<li>  integer promotion rules
-<li>  macros with a variable number of arguments
-<li>  the vscanf family of functions in <a href="#7.21">&lt;stdio.h&gt;</a> and <a href="#7.28">&lt;wchar.h&gt;</a>
-<li>  additional math library functions in <a href="#7.12">&lt;math.h&gt;</a>
-<li>  treatment of error conditions by math library functions (math_errhandling)
-<li>  floating-point environment access in <a href="#7.6">&lt;fenv.h&gt;</a>
-<li>  IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
-<li>  trailing comma allowed in enum declaration
-<li>  %lf conversion specifier allowed in printf
-<li>  inline functions
-<li>  the snprintf family of functions in <a href="#7.21">&lt;stdio.h&gt;</a>
-<li>  boolean type in <a href="#7.18">&lt;stdbool.h&gt;</a>
-<li>  idempotent type qualifiers
-<li>  empty macro arguments
-<li>  new structure type compatibility rules (tag compatibility)
-<li>  additional predefined macro names
-<li>  _Pragma preprocessing operator
-<li>  standard pragmas
-<li>  __func__ predefined identifier
-<li>  va_copy macro
-<li>  additional strftime conversion specifiers
-<li>  LIA compatibility annex
-<!--page 16 -->
-<li>  deprecate ungetc at the beginning of a binary file
-<li>  remove deprecation of aliased array parameters
-<li>  conversion of array to pointer not limited to lvalues
-<li>  relaxed constraints on aggregate and union initialization
-<li>  relaxed restrictions on portable header names
-<li>  return without expression not permitted in function that returns a value (and vice
- versa)
-</ul>
-<p><!--para 8 -->
- Annexes D, F, G, K, and L form a normative part of this standard; annexes A, B, C, E, H, *
- I, J, the bibliography, and the index are for information only. In accordance with Part 2 of
- the ISO/IEC Directives, this foreword, the introduction, notes, footnotes, and examples
- are also for information only.
-<!--page 17 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="Introduction" href="#Introduction">Introduction</a></h2>
-<p><!--para 1 -->
- With the introduction of new devices and extended character sets, new features may be
- added to this International Standard. Subclauses in the language and library clauses warn
- implementors and programmers of usages which, though valid in themselves, may
- conflict with future additions.
-<p><!--para 2 -->
- Certain features are obsolescent, which means that they may be considered for
- withdrawal in future revisions of this International Standard. They are retained because
- of their widespread use, but their use in new implementations (for implementation
- features) or new programs (for language [<a href="#6.11">6.11</a>] or library features [<a href="#7.30">7.30</a>]) is discouraged.
-<p><!--para 3 -->
- This International Standard is divided into four major subdivisions:
-<ul>
-<li>  preliminary elements (clauses 1-4);
-<li>  the characteristics of environments that translate and execute C programs (clause 5);
-<li>  the language syntax, constraints, and semantics (clause 6);
-<li>  the library facilities (clause 7).
-</ul>
-<p><!--para 4 -->
- Examples are provided to illustrate possible forms of the constructions described.
- Footnotes are provided to emphasize consequences of the rules described in that
- subclause or elsewhere in this International Standard. References are used to refer to
- other related subclauses. Recommendations are provided to give advice or guidance to
- implementors. Annexes provide additional information and summarize the information
- contained in this International Standard. A bibliography lists documents that were
- referred to during the preparation of the standard.
-<p><!--para 5 -->
- The language clause (clause 6) is derived from ''The C Reference Manual''.
-<p><!--para 6 -->
- The library clause (clause 7) is based on the 1984 /usr/group Standard.
-<!--page 18 -->
-<!--page 19 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h1>Programming languages -- C</h1>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="1" href="#1">1. Scope</a></h2>
-<p><!--para 1 -->
- This International Standard specifies the form and establishes the interpretation of
- programs written in the C programming language.<sup><a href="#note1"><b>1)</b></a></sup> It specifies
-<ul>
-<li>  the representation of C programs;
-<li>  the syntax and constraints of the C language;
-<li>  the semantic rules for interpreting C programs;
-<li>  the representation of input data to be processed by C programs;
-<li>  the representation of output data produced by C programs;
-<li>  the restrictions and limits imposed by a conforming implementation of C.
-</ul>
-<p><!--para 2 -->
- This International Standard does not specify
-<ul>
-<li>  the mechanism by which C programs are transformed for use by a data-processing
- system;
-<li>  the mechanism by which C programs are invoked for use by a data-processing
- system;
-<li>  the mechanism by which input data are transformed for use by a C program;
-<li>  the mechanism by which output data are transformed after being produced by a C
- program;
-<li>  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;
-<li>  all minimal requirements of a data-processing system that is capable of supporting a
- conforming implementation.
-<!--page 20 -->
-</ul>
-
-<p><b>Footnotes</b>
-<p><small><a name="note1" href="#note1">1)</a> This International Standard is designed to promote the portability of C programs among a variety of
- data-processing systems. It is intended for use by implementors and programmers.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="2" href="#2">2. Normative references</a></h2>
-<p><!--para 1 -->
- The following referenced documents are indispensable for the application of this
- document. For dated references, only the edition cited applies. For undated references,
- the latest edition of the referenced document (including any amendments) applies.
-<p><!--para 2 -->
- ISO 31-11:1992, Quantities and units -- Part 11: Mathematical signs and symbols for
- use in the physical sciences and technology.
-<p><!--para 3 -->
- ISO/IEC 646, Information technology -- ISO 7-bit coded character set for information
- interchange.
-<p><!--para 4 -->
- ISO/IEC 2382-1:1993, Information technology -- Vocabulary -- Part 1: Fundamental
- terms.
-<p><!--para 5 -->
- ISO 4217, Codes for the representation of currencies and funds.
-<p><!--para 6 -->
- ISO 8601, Data elements and interchange formats -- Information interchange --
- Representation of dates and times.
-<p><!--para 7 -->
- ISO/IEC 10646 (all parts), Information technology -- Universal Multiple-Octet Coded
- Character Set (UCS).
-<p><!--para 8 -->
- IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems (previously
- designated IEC 559:1989).
-<!--page 21 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="3" href="#3">3. Terms, definitions, and symbols</a></h2>
-<p><!--para 1 -->
- For the purposes of this International Standard, the following definitions apply. Other
- terms are defined where they appear in italic type or on the left side of a syntax rule.
- Terms explicitly defined in this International Standard are not to be presumed to refer
- implicitly to similar terms defined elsewhere. Terms not defined in this International
- Standard are to be interpreted according to ISO/IEC 2382-1. Mathematical symbols not
- defined in this International Standard are to be interpreted according to ISO 31-11.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.1" href="#3.1">3.1</a></h3>
-<p><!--para 1 -->
-<b> access</b><br>
- &lt;execution-time action&gt; to read or modify the value of an object
-<p><!--para 2 -->
- NOTE 1   Where only one of these two actions is meant, ''read'' or ''modify'' is used.
-<p><!--para 3 -->
- NOTE 2   ''Modify'' includes the case where the new value being stored is the same as the previous value.
-<p><!--para 4 -->
- NOTE 3   Expressions that are not evaluated do not access objects.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.2" href="#3.2">3.2</a></h3>
-<p><!--para 1 -->
-<b> alignment</b><br>
- requirement that objects of a particular type be located on storage boundaries with
- addresses that are particular multiples of a byte address
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.3" href="#3.3">3.3</a></h3>
-<p><!--para 1 -->
-<b> argument</b><br>
- actual argument
- actual parameter (deprecated)
- 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
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.4" href="#3.4">3.4</a></h3>
-<p><!--para 1 -->
-<b> behavior</b><br>
- external appearance or action
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.4.1" href="#3.4.1">3.4.1</a></h4>
-<p><!--para 1 -->
-<b> implementation-defined behavior</b><br>
- unspecified behavior where each implementation documents how the choice is made
-<p><!--para 2 -->
- EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit
- when a signed integer is shifted right.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.4.2" href="#3.4.2">3.4.2</a></h4>
-<p><!--para 1 -->
-<b> locale-specific behavior</b><br>
- behavior that depends on local conventions of nationality, culture, and language that each
- implementation documents
-<!--page 22 -->
-<p><!--para 2 -->
- EXAMPLE An example of locale-specific behavior is whether the islower function returns true for
- characters other than the 26 lowercase Latin letters.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.4.3" href="#3.4.3">3.4.3</a></h4>
-<p><!--para 1 -->
-<b> undefined behavior</b><br>
- behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
- for which this International Standard imposes no requirements
-<p><!--para 2 -->
- NOTE Possible 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).
-<p><!--para 3 -->
- EXAMPLE        An example of undefined behavior is the behavior on integer overflow.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.4.4" href="#3.4.4">3.4.4</a></h4>
-<p><!--para 1 -->
-<b> unspecified behavior</b><br>
- use of an unspecified value, or other behavior where this International Standard provides
- two or more possibilities and imposes no further requirements on which is chosen in any
- instance
-<p><!--para 2 -->
- EXAMPLE        An example of unspecified behavior is the order in which the arguments to a function are
- evaluated.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.5" href="#3.5">3.5</a></h3>
-<p><!--para 1 -->
-<b> bit</b><br>
- unit of data storage in the execution environment large enough to hold an object that may
- have one of two values
-<p><!--para 2 -->
- NOTE     It need not be possible to express the address of each individual bit of an object.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.6" href="#3.6">3.6</a></h3>
-<p><!--para 1 -->
-<b> byte</b><br>
- addressable unit of data storage large enough to hold any member of the basic character
- set of the execution environment
-<p><!--para 2 -->
- NOTE 1     It is possible to express the address of each individual byte of an object uniquely.
-<p><!--para 3 -->
- NOTE 2 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.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.7" href="#3.7">3.7</a></h3>
-<p><!--para 1 -->
-<b> character</b><br>
- &lt;abstract&gt; member of a set of elements used for the organization, control, or
- representation of data
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.7.1" href="#3.7.1">3.7.1</a></h4>
-<p><!--para 1 -->
-<b> character</b><br>
- single-byte character
- &lt;C&gt; bit representation that fits in a byte
-<!--page 23 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.7.2" href="#3.7.2">3.7.2</a></h4>
-<p><!--para 1 -->
-<b> multibyte character</b><br>
- sequence of one or more bytes representing a member of the extended character set of
- either the source or the execution environment
-<p><!--para 2 -->
- NOTE    The extended character set is a superset of the basic character set.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.7.3" href="#3.7.3">3.7.3</a></h4>
-<p><!--para 1 -->
-<b> wide character</b><br>
- bit representation that fits in an object of type wchar_t, capable of representing any
- character in the current locale
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.8" href="#3.8">3.8</a></h3>
-<p><!--para 1 -->
-<b> constraint</b><br>
- restriction, either syntactic or semantic, by which the exposition of language elements is
- to be interpreted
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.9" href="#3.9">3.9</a></h3>
-<p><!--para 1 -->
-<b> correctly rounded result</b><br>
- representation in the result format that is nearest in value, subject to the current rounding
- mode, to what the result would be given unlimited range and precision
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.10" href="#3.10">3.10</a></h3>
-<p><!--para 1 -->
-<b> diagnostic message</b><br>
- message belonging to an implementation-defined subset of the implementation's message
- output
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.11" href="#3.11">3.11</a></h3>
-<p><!--para 1 -->
-<b> forward reference</b><br>
- reference to a later subclause of this International Standard that contains additional
- information relevant to this subclause
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.12" href="#3.12">3.12</a></h3>
-<p><!--para 1 -->
-<b> implementation</b><br>
- 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
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.13" href="#3.13">3.13</a></h3>
-<p><!--para 1 -->
-<b> implementation limit</b><br>
- restriction imposed upon programs by the implementation
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.14" href="#3.14">3.14</a></h3>
-<p><!--para 1 -->
-<b> memory location</b><br>
- either an object of scalar type, or a maximal sequence of adjacent bit-fields all having
- nonzero width
-<!--page 24 -->
-<p><!--para 2 -->
- NOTE 1 Two threads of execution can update and access separate memory locations without interfering
- with each other.
-<p><!--para 3 -->
- NOTE 2 A bit-field and an adjacent non-bit-field member are in separate memory locations. The same
- applies to two bit-fields, if one is declared inside a nested structure declaration and the other is not, or if the
- two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field member
- declaration. It is not safe to concurrently update two non-atomic bit-fields in the same structure if all
- members declared between them are also (non-zero-length) bit-fields, no matter what the sizes of those
- intervening bit-fields happen to be.
-<p><!--para 4 -->
- EXAMPLE        A structure declared as
-<pre>
-          struct {
-                char a;
-                int b:5, c:11, :0, d:8;
-                struct { int ee:8; } e;
-          }
-</pre>
- contains four separate memory locations: The member a, and bit-fields d and e.ee are each separate
- memory locations, and can be modified concurrently without interfering with each other. The bit-fields b
- and c together constitute the fourth memory location. The bit-fields b and c cannot be concurrently
- modified, but b and a, for example, can be.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.15" href="#3.15">3.15</a></h3>
-<p><!--para 1 -->
-<b> object</b><br>
- region of data storage in the execution environment, the contents of which can represent
- values
-<p><!--para 2 -->
- NOTE      When referenced, an object may be interpreted as having a particular type; see <a href="#6.3.2.1">6.3.2.1</a>.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.16" href="#3.16">3.16</a></h3>
-<p><!--para 1 -->
-<b> parameter</b><br>
- formal parameter
- formal argument (deprecated)
- 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
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.17" href="#3.17">3.17</a></h3>
-<p><!--para 1 -->
-<b> recommended practice</b><br>
- specification that is strongly recommended as being in keeping with the intent of the
- standard, but that may be impractical for some implementations
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.18" href="#3.18">3.18</a></h3>
-<p><!--para 1 -->
-<b> runtime-constraint</b><br>
- requirement on a program when calling a library function
-<p><!--para 2 -->
- NOTE 1 Despite the similar terms, a runtime-constraint is not a kind of constraint as defined by <a href="#3.8">3.8</a>, and
- need not be diagnosed at translation time.
-<p><!--para 3 -->
- NOTE 2 Implementations that support the extensions in <a href="#K">annex K</a> are required to verify that the runtime-
- constraints for a library function are not violated by the program; see <a href="#K.3.1.4">K.3.1.4</a>.
-<!--page 25 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.19" href="#3.19">3.19</a></h3>
-<p><!--para 1 -->
-<b> value</b><br>
- precise meaning of the contents of an object when interpreted as having a specific type
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.19.1" href="#3.19.1">3.19.1</a></h4>
-<p><!--para 1 -->
-<b> implementation-defined value</b><br>
- unspecified value where each implementation documents how the choice is made
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.19.2" href="#3.19.2">3.19.2</a></h4>
-<p><!--para 1 -->
-<b> indeterminate value</b><br>
- either an unspecified value or a trap representation
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.19.3" href="#3.19.3">3.19.3</a></h4>
-<p><!--para 1 -->
-<b> unspecified value</b><br>
- valid value of the relevant type where this International Standard imposes no
- requirements on which value is chosen in any instance
-<p><!--para 2 -->
- NOTE     An unspecified value cannot be a trap representation.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.19.4" href="#3.19.4">3.19.4</a></h4>
-<p><!--para 1 -->
-<b> trap representation</b><br>
- an object representation that need not represent a value of the object type
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="3.19.5" href="#3.19.5">3.19.5</a></h4>
-<p><!--para 1 -->
-<b> perform a trap</b><br>
- interrupt execution of the program such that no further operations are performed
-<p><!--para 2 -->
- NOTE In this International Standard, when the word ''trap'' is not immediately followed by
- ''representation'', this is the intended usage.<sup><a href="#note2"><b>2)</b></a></sup>
-
-<p><b>Footnotes</b>
-<p><small><a name="note2" href="#note2">2)</a> For example, ''Trapping or stopping (if supported) is disabled...'' (<a href="#F.8.2">F.8.2</a>). Note that fetching a trap
- representation might perform a trap but is not required to (see <a href="#6.2.6.1">6.2.6.1</a>).
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.20" href="#3.20">3.20</a></h3>
-<p><!--para 1 -->
-<b> [^ x^]</b><br>
- ceiling of x: the least integer greater than or equal to x
-<p><!--para 2 -->
- EXAMPLE       [^2.4^] is 3, [^-2.4^] is -2.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="3.21" href="#3.21">3.21</a></h3>
-<p><!--para 1 -->
-<b> [_ x_]</b><br>
- floor of x: the greatest integer less than or equal to x
-<p><!--para 2 -->
- EXAMPLE       [_2.4_] is 2, [_-2.4_] is -3.
-<!--page 26 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="4" href="#4">4. Conformance</a></h2>
-<p><!--para 1 -->
- In this International 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.
-<p><!--para 2 -->
- If a ''shall'' or ''shall not'' requirement that appears outside of a constraint or runtime-
- constraint is violated, the behavior is undefined. Undefined behavior is otherwise
- indicated in this International 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''.
-<p><!--para 3 -->
- A program that is correct in all other aspects, operating on correct data, containing
- unspecified behavior shall be a correct program and act in accordance with <a href="#5.1.2.3">5.1.2.3</a>.
-<p><!--para 4 -->
- The implementation shall not successfully translate a preprocessing translation unit
- containing a #error preprocessing directive unless it is part of a group skipped by
- conditional inclusion.
-<p><!--para 5 -->
- A strictly conforming program shall use only those features of the language and library
- specified in this International Standard.<sup><a href="#note3"><b>3)</b></a></sup> It shall not produce output dependent on any
- unspecified, undefined, or implementation-defined behavior, and shall not exceed any
- minimum implementation limit.
-<p><!--para 6 -->
- 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 that does not
- use complex types and in which the use of the features specified in the library clause
- (clause 7) is confined to the contents of the standard headers <a href="#7.7">&lt;float.h&gt;</a>,
- <a href="#7.9">&lt;iso646.h&gt;</a>, <a href="#7.10">&lt;limits.h&gt;</a>, <a href="#7.15">&lt;stdalign.h&gt;</a>, <a href="#7.16">&lt;stdarg.h&gt;</a>, <a href="#7.18">&lt;stdbool.h&gt;</a>,
- <a href="#7.19">&lt;stddef.h&gt;</a>, and <a href="#7.20">&lt;stdint.h&gt;</a>. A conforming implementation may have extensions
- (including additional library functions), provided they do not alter the behavior of any
- strictly conforming program.<sup><a href="#note4"><b>4)</b></a></sup>
-<!--page 27 -->
-<p><!--para 7 -->
- A conforming program is one that is acceptable to a conforming implementation.<sup><a href="#note5"><b>5)</b></a></sup>
-<p><!--para 8 -->
- An implementation shall be accompanied by a document that defines all implementation-
- defined and locale-specific characteristics and all extensions.
-<p><b> Forward references</b>: conditional inclusion (<a href="#6.10.1">6.10.1</a>), error directive (<a href="#6.10.5">6.10.5</a>),
- characteristics of floating types <a href="#7.7">&lt;float.h&gt;</a> (<a href="#7.7">7.7</a>), alternative spellings <a href="#7.9">&lt;iso646.h&gt;</a>
- (<a href="#7.9">7.9</a>), sizes of integer types <a href="#7.10">&lt;limits.h&gt;</a> (<a href="#7.10">7.10</a>), alignment <a href="#7.15">&lt;stdalign.h&gt;</a> (<a href="#7.15">7.15</a>),
- variable arguments <a href="#7.16">&lt;stdarg.h&gt;</a> (<a href="#7.16">7.16</a>), boolean type and values <a href="#7.18">&lt;stdbool.h&gt;</a>
- (<a href="#7.18">7.18</a>), common definitions <a href="#7.19">&lt;stddef.h&gt;</a> (<a href="#7.19">7.19</a>), integer types <a href="#7.20">&lt;stdint.h&gt;</a> (<a href="#7.20">7.20</a>).
-<!--page 28 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note3" href="#note3">3)</a> A strictly conforming program can use conditional features (see <a href="#6.10.8.3">6.10.8.3</a>) provided the use is guarded
- by an appropriate conditional inclusion preprocessing directive using the related macro. For example:
-
-<pre>
-         #ifdef __STDC_IEC_559__ /* FE_UPWARD defined */
-            /* ... */
-            fesetround(FE_UPWARD);
-            /* ... */
-         #endif
-</pre>
-</small>
-<p><small><a name="note4" href="#note4">4)</a> This implies that a conforming implementation reserves no identifiers other than those explicitly
- reserved in this International Standard.
-</small>
-<p><small><a name="note5" href="#note5">5)</a> Strictly conforming programs are intended to be maximally portable among conforming
- implementations. Conforming programs may depend upon nonportable features of a conforming
- implementation.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="5" href="#5">5. Environment</a></h2>
-<p><!--para 1 -->
- 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 International Standard. Their characteristics define and
- constrain the results of executing conforming C programs constructed according to the
- syntactic and semantic rules for conforming implementations.
-<p><b> Forward references</b>: In this clause, only a few of many possible forward references
- have been noted.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="5.1" href="#5.1">5.1 Conceptual models</a></h3>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="5.1.1" href="#5.1.1">5.1.1 Translation environment</a></h4>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.1.1" href="#5.1.1.1">5.1.1.1 Program structure</a></h5>
-<p><!--para 1 -->
- A C program need not all be translated at the same time. The text of the program is kept
- in units called source files, (or preprocessing files) in this International Standard. A
- source file together with all the headers and source files included via the preprocessing
- directive #include is known as a preprocessing translation unit. After preprocessing, a
- preprocessing translation unit 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, manipulation of objects whose identifiers have external linkage, or manipulation
- of data files. Translation units may be separately translated and then later linked to
- produce an executable program.
-<p><b> Forward references</b>: linkages of identifiers (<a href="#6.2.2">6.2.2</a>), external definitions (<a href="#6.9">6.9</a>),
- preprocessing directives (<a href="#6.10">6.10</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.1.2" href="#5.1.1.2">5.1.1.2 Translation phases</a></h5>
-<p><!--para 1 -->
- The precedence among the syntax rules of translation is specified by the following
- phases.<sup><a href="#note6"><b>6)</b></a></sup>
-<ol>
-<li>  Physical source file multibyte characters are mapped, in an implementation-
- defined manner, 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.
-<!--page 29 -->
-<li>  Each instance of a backslash character (\) immediately followed by a new-line
- character is deleted, splicing physical source lines to form logical source lines.
- Only the last backslash on any physical source line shall be eligible for being part
- of such a splice. A source file that is not empty shall end in a new-line character,
- which shall not be immediately preceded by a backslash character before any such
- splicing takes place.
-<li>  The source file is decomposed into preprocessing tokens<sup><a href="#note7"><b>7)</b></a></sup> and sequences of
- white-space characters (including comments). A source file shall not end in a
- partial preprocessing token or in a partial comment. Each comment is replaced by
- one space character. New-line characters are retained. Whether each nonempty
- sequence of white-space characters other than new-line is retained or replaced by
- one space character is implementation-defined.
-<li>  Preprocessing directives are executed, macro invocations are expanded, and
- _Pragma unary operator expressions are executed. If a character sequence that
- matches the syntax of a universal character name is produced by token
- concatenation (<a href="#6.10.3.3">6.10.3.3</a>), the behavior is undefined. A #include preprocessing
- directive causes the named header or source file to be processed from phase 1
- through phase 4, recursively. All preprocessing directives are then deleted.
-<li>  Each source character set member and escape sequence in character constants and
- string literals is converted to the corresponding member of the execution character
- set; if there is no corresponding member, it is converted to an implementation-
- defined member other than the null (wide) character.<sup><a href="#note8"><b>8)</b></a></sup>
-<li>  Adjacent string literal tokens are concatenated.
-<li>  White-space characters separating tokens are no longer significant. Each
- preprocessing token is converted into a token. The resulting tokens are
- syntactically and semantically analyzed and translated as a translation unit.
-<li>  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.
-</ol>
-<p><b> Forward references</b>: universal character names (<a href="#6.4.3">6.4.3</a>), lexical elements (<a href="#6.4">6.4</a>),
- preprocessing directives (<a href="#6.10">6.10</a>), trigraph sequences (<a href="#5.2.1.1">5.2.1.1</a>), external definitions (<a href="#6.9">6.9</a>).
-<!--page 30 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note6" href="#note6">6)</a> Implementations shall behave as if these separate phases occur, even though many are typically folded
- together in practice. Source files, translation units, and translated translation units need not
- necessarily be stored as files, nor need there be any one-to-one correspondence between these entities
- and any external representation. The description is conceptual only, and does not specify any
- particular implementation.
-</small>
-<p><small><a name="note7" href="#note7">7)</a> As described in <a href="#6.4">6.4</a>, the process of dividing a source file's characters into preprocessing tokens is
- context-dependent. For example, see the handling of &lt; within a #include preprocessing directive.
-</small>
-<p><small><a name="note8" href="#note8">8)</a> An implementation need not convert all non-corresponding source characters to the same execution
- character.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.1.3" href="#5.1.1.3">5.1.1.3 Diagnostics</a></h5>
-<p><!--para 1 -->
- A conforming implementation shall produce at least one diagnostic message (identified in
- an implementation-defined manner) if a preprocessing translation unit or translation unit
- contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
- specified as undefined or implementation-defined. Diagnostic messages need not be
- produced in other circumstances.<sup><a href="#note9"><b>9)</b></a></sup>
-<p><!--para 2 -->
- EXAMPLE        An implementation shall issue a diagnostic for the translation unit:
-<pre>
-          char i;
-          int i;
-</pre>
- because in those cases where wording in this International Standard describes the behavior for a construct
- as being both a constraint error and resulting in undefined behavior, the constraint error shall be diagnosed.
-
-<p><b>Footnotes</b>
-<p><small><a name="note9" href="#note9">9)</a> The intent is that an implementation should identify the nature of, and where possible localize, each
- violation. Of course, an implementation is free to produce any number of diagnostics as long as a
- valid program is still correctly translated. It may also successfully translate an invalid program.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="5.1.2" href="#5.1.2">5.1.2 Execution environments</a></h4>
-<p><!--para 1 -->
- 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 with static storage duration 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.
-<p><b> Forward references</b>: storage durations of objects (<a href="#6.2.4">6.2.4</a>), initialization (<a href="#6.7.9">6.7.9</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.2.1" href="#5.1.2.1">5.1.2.1 Freestanding environment</a></h5>
-<p><!--para 1 -->
- 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. Any library facilities available to a freestanding
- program, other than the minimal set required by clause 4, are implementation-defined.
-<p><!--para 2 -->
- The effect of program termination in a freestanding environment is implementation-
- defined.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.2.2" href="#5.1.2.2">5.1.2.2 Hosted environment</a></h5>
-<p><!--para 1 -->
- A hosted environment need not be provided, but shall conform to the following
- specifications if present.
-<!--page 31 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.2.2.1" href="#5.1.2.2.1">5.1.2.2.1 Program startup</a></h5>
-<p><!--para 1 -->
- The function called at program startup is named main. The implementation declares no
- prototype for this function. It shall be defined with a return type of int and with no
- parameters:
-<pre>
-         int main(void) { /* ... */ }
-</pre>
- 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):
-<pre>
-         int main(int argc, char *argv[]) { /* ... */ }
-</pre>
- or equivalent;<sup><a href="#note10"><b>10)</b></a></sup> or in some other implementation-defined manner.
-<p><!--para 2 -->
- If they are declared, the parameters to the main function shall obey the following
- constraints:
-<ul>
-<li>  The value of argc shall be nonnegative.
-<li>  argv[argc] shall be a null pointer.
-<li>  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 uppercase and lowercase, the implementation
- shall ensure that the strings are received in lowercase.
-<li>  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.
-<li>  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.
-</ul>
-
-<p><b>Footnotes</b>
-<p><small><a name="note10" href="#note10">10)</a> Thus, int can be replaced by a typedef name defined as int, or the type of argv can be written as
- char ** argv, and so on.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.2.2.2" href="#5.1.2.2.2">5.1.2.2.2 Program execution</a></h5>
-<p><!--para 1 -->
- In a hosted environment, a program may use all the functions, macros, type definitions,
- and objects described in the library clause (clause 7).
-<!--page 32 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.2.2.3" href="#5.1.2.2.3">5.1.2.2.3 Program termination</a></h5>
-<p><!--para 1 -->
- If the return type of the main function is a type compatible with int, 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;<sup><a href="#note11"><b>11)</b></a></sup> reaching the } that terminates the
- main function returns a value of 0. If the return type is not compatible with int, the
- termination status returned to the host environment is unspecified.
-<p><b> Forward references</b>: definition of terms (<a href="#7.1.1">7.1.1</a>), the exit function (<a href="#7.22.4.4">7.22.4.4</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note11" href="#note11">11)</a> In accordance with <a href="#6.2.4">6.2.4</a>, the lifetimes of objects with automatic storage duration declared in main
- will have ended in the former case, even where they would not have in the latter.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.2.3" href="#5.1.2.3">5.1.2.3 Program execution</a></h5>
-<p><!--para 1 -->
- The semantic descriptions in this International Standard describe the behavior of an
- abstract machine in which issues of optimization are irrelevant.
-<p><!--para 2 -->
- Accessing a volatile object, modifying an object, modifying a file, or calling a function
- that does any of those operations are all side effects,<sup><a href="#note12"><b>12)</b></a></sup> which are changes in the state of
- the execution environment. Evaluation of an expression in general includes both value
- computations and initiation of side effects. Value computation for an lvalue expression
- includes determining the identity of the designated object.
-<p><!--para 3 -->
- Sequenced before is an asymmetric, transitive, pair-wise relation between evaluations
- executed by a single thread, which induces a partial order among those evaluations.
- Given any two evaluations A and B, if A is sequenced before B, then the execution of A
- shall precede the execution of B. (Conversely, if A is sequenced before B, then B is
- sequenced after A.) If A is not sequenced before or after B, then A and B are
- unsequenced. Evaluations A and B are indeterminately sequenced when A is sequenced
- either before or after B, but it is unspecified which.<sup><a href="#note13"><b>13)</b></a></sup> The presence of a sequence point
- between the evaluation of expressions A and B implies that every value computation and
- side effect associated with A is sequenced before every value computation and side effect
- associated with B. (A summary of the sequence points is given in <a href="#C">annex C</a>.)
-<p><!--para 4 -->
- 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
-<!--page 33 -->
- calling a function or accessing a volatile object).
-<p><!--para 5 -->
- When the processing of the abstract machine is interrupted by receipt of a signal, the
- values of objects that are neither lock-free atomic objects nor of type volatile
- sig_atomic_t are unspecified, and the value of any object that is modified by the
- handler that is neither a lock-free atomic object nor of type volatile
- sig_atomic_t becomes undefined.
-<p><!--para 6 -->
- The least requirements on a conforming implementation are:
-<ul>
-<li>  Accesses to volatile objects are evaluated strictly according to the rules of the abstract
- machine.
-<li>  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.
-<li>  The input and output dynamics of interactive devices shall take place as specified in
- <a href="#7.21.3">7.21.3</a>. 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.
-</ul>
- This is the observable behavior of the program.
-<p><!--para 7 -->
- What constitutes an interactive device is implementation-defined.
-<p><!--para 8 -->
- More stringent correspondences between abstract and actual semantics may be defined by
- each implementation.
-<p><!--para 9 -->
- EXAMPLE 1 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.
-<p><!--para 10 -->
- 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.
-<p><!--para 11 -->
- EXAMPLE 2       In executing the fragment
-<pre>
-          char c1, c2;
-          /* ... */
-          c1 = c1 + c2;
-</pre>
- the ''integer promotions'' require that the abstract machine promote the value of each variable to int size
- and then add the two ints and truncate the sum. Provided the addition of two chars can be done without
- overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only
- produce the same result, possibly omitting the promotions.
-<!--page 34 -->
-<p><!--para 12 -->
- EXAMPLE 3       Similarly, in the fragment
-<pre>
-          float f1, f2;
-          double d;
-          /* ... */
-          f1 = f2 * d;
-</pre>
- 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).
-<p><!--para 13 -->
- EXAMPLE 4 Implementations employing wide registers have to take care to honor appropriate
- semantics. Values are independent of whether they are represented in a register or in memory. For
- example, an implicit spilling of a register is not permitted to alter the value. Also, an explicit store and load
- is required to round to the precision of the storage type. In particular, casts and assignments are required to
- perform their specified conversion. For the fragment
-<pre>
-          double d1, d2;
-          float f;
-          d1 = f = expression;
-          d2 = (float) expression;
-</pre>
- the values assigned to d1 and d2 are required to have been converted to float.
-<p><!--para 14 -->
- EXAMPLE 5 Rearrangement for floating-point expressions is often restricted because of limitations in
- precision as well as range. The implementation cannot generally apply the mathematical associative rules
- for addition or multiplication, nor the distributive rule, because of roundoff error, even in the absence of
- overflow and underflow. Likewise, implementations cannot generally replace decimal constants in order to
- rearrange expressions. In the following fragment, rearrangements suggested by mathematical rules for real
- numbers are often not valid (see <a href="#F.9">F.9</a>).
-<pre>
-          double x, y, z;
-          /* ... */
-          x = (x * y) * z;            //   not equivalent to x   *= y * z;
-          z = (x - y) + y ;           //   not equivalent to z   = x;
-          z = x + x * y;              //   not equivalent to z   = x * (1.0 + y);
-          y = x / 5.0;                //   not equivalent to y   = x * 0.2;
-</pre>
-<p><!--para 15 -->
- EXAMPLE 6       To illustrate the grouping behavior of expressions, in the following fragment
-<pre>
-          int a, b;
-          /* ... */
-          a = a + 32760 + b + 5;
-</pre>
- the expression statement behaves exactly the same as
-<pre>
-          a = (((a + 32760) + b) + 5);
-</pre>
- due to the associativity and precedence of these operators. Thus, the result of the sum (a + 32760) is
- next added to b, and that result is then added to 5 which results in the value assigned to a. On a machine in
- which overflows produce an explicit trap and in which the range of values representable by an int is
- [-32768, +32767], the implementation cannot rewrite this expression as
-<pre>
-          a = ((a + b) + 32765);
-</pre>
- since if the values for a and b were, respectively, -32754 and -15, the sum a + b would produce a trap
- while the original expression would not; nor can the expression be rewritten either as
-<!--page 35 -->
-<pre>
-          a = ((a + 32765) + b);
-</pre>
- or
-<pre>
-          a = (a + (b + 32765));
-</pre>
- since the values for a and b might have been, respectively, 4 and -8 or -17 and 12. However, on a machine
- in which overflow silently generates some value and where positive and negative overflows cancel, the
- above expression statement can be rewritten by the implementation in any of the above ways because the
- same result will occur.
-<p><!--para 16 -->
- EXAMPLE 7 The grouping of an expression does not completely determine its evaluation. In the
- following fragment
-<pre>
-          #include <a href="#7.21">&lt;stdio.h&gt;</a>
-          int sum;
-          char *p;
-          /* ... */
-          sum = sum * 10 - '0' + (*p++ = getchar());
-</pre>
- the expression statement is grouped as if it were written as
-<pre>
-          sum = (((sum * 10) - '0') + ((*(p++)) = (getchar())));
-</pre>
- but the actual increment of p can occur at any time between the previous sequence point and the next
- sequence point (the ;), and the call to getchar can occur at any point prior to the need of its returned
- value.
-<p><b> Forward references</b>: expressions (<a href="#6.5">6.5</a>), type qualifiers (<a href="#6.7.3">6.7.3</a>), statements (<a href="#6.8">6.8</a>), the
- signal function (<a href="#7.14">7.14</a>), files (<a href="#7.21.3">7.21.3</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note12" href="#note12">12)</a> The IEC 60559 standard for binary floating-point arithmetic requires certain user-accessible status
- flags and control modes. Floating-point operations implicitly set the status flags; modes affect result
- values of floating-point operations. Implementations that support such floating-point state are
- required to regard changes to it as side effects -- see <a href="#F">annex F</a> for details. The floating-point
- environment library <a href="#7.6">&lt;fenv.h&gt;</a> provides a programming facility for indicating when these side
- effects matter, freeing the implementations in other cases.
-</small>
-<p><small><a name="note13" href="#note13">13)</a> The executions of unsequenced evaluations can interleave. Indeterminately sequenced evaluations
- cannot interleave, but can be executed in any order.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.1.2.4" href="#5.1.2.4">5.1.2.4 Multi-threaded executions and data races</a></h5>
-<p><!--para 1 -->
- Under a hosted implementation, a program can have more than one thread of execution
- (or thread) running concurrently. The execution of each thread proceeds as defined by
- the remainder of this standard. The execution of the entire program consists of an
- execution of all of its threads.<sup><a href="#note14"><b>14)</b></a></sup> Under a freestanding implementation, it is
- implementation-defined whether a program can have more than one thread of execution.
-<p><!--para 2 -->
- The value of an object visible to a thread T at a particular point is the initial value of the
- object, a value stored in the object by T , or a value stored in the object by another thread,
- according to the rules below.
-<p><!--para 3 -->
- NOTE 1 In some cases, there may instead be undefined behavior. Much of this section is motivated by
- the desire to support atomic operations with explicit and detailed visibility constraints. However, it also
- implicitly supports a simpler view for more restricted programs.
-<p><!--para 4 -->
- Two expression evaluations conflict if one of them modifies a memory location and the
- other one reads or modifies the same memory location.
-<!--page 36 -->
-<p><!--para 5 -->
- The library defines a number of atomic operations (<a href="#7.17">7.17</a>) and operations on mutexes
- (<a href="#7.25.4">7.25.4</a>) that are specially identified as synchronization operations. These operations play
- a special role in making assignments in one thread visible to another. A synchronization
- operation on one or more memory locations is either an acquire operation, a release
- operation, both an acquire and release operation, or a consume operation. A
- synchronization operation without an associated memory location is a fence and can be
- either an acquire fence, a release fence, or both an acquire and release fence. In addition,
- there are relaxed atomic operations, which are not synchronization operations, and
- atomic read-modify-write operations, which have special characteristics.
-<p><!--para 6 -->
- NOTE 2 For example, a call that acquires a mutex will perform an acquire operation on the locations
- composing the mutex. Correspondingly, a call that releases the same mutex will perform a release
- operation on those same locations. Informally, performing a release operation on A forces prior side effects
- on other memory locations to become visible to other threads that later perform an acquire or consume
- operation on A. We do not include relaxed atomic operations as synchronization operations although, like
- synchronization operations, they cannot contribute to data races.
-<p><!--para 7 -->
- All modifications to a particular atomic object M occur in some particular total order,
- called the modification order of M. If A and B are modifications of an atomic object M,
- and A happens before B, then A shall precede B in the modification order of M, which is
- defined below.
-<p><!--para 8 -->
- NOTE 3     This states that the modification orders must respect the ''happens before'' relation.
-<p><!--para 9 -->
- NOTE 4 There is a separate order for each atomic object. There is no requirement that these can be
- combined into a single total order for all objects. In general this will be impossible since different threads
- may observe modifications to different variables in inconsistent orders.
-<p><!--para 10 -->
- A release sequence on an atomic object M is a maximal contiguous sub-sequence of side
- effects in the modification order of M, where the first operation is a release and every
- subsequent operation either is performed by the same thread that performed the release or
- is an atomic read-modify-write operation.
-<p><!--para 11 -->
- Certain library calls synchronize with other library calls performed by another thread. In
- particular, an atomic operation A that performs a release operation on an object M
- synchronizes with an atomic operation B that performs an acquire operation on M and
- reads a value written by any side effect in the release sequence headed by A.
-<p><!--para 12 -->
- NOTE 5 Except in the specified cases, reading a later value does not necessarily ensure visibility as
- described below. Such a requirement would sometimes interfere with efficient implementation.
-<p><!--para 13 -->
- NOTE 6 The specifications of the synchronization operations define when one reads the value written by
- another. For atomic variables, the definition is clear. All operations on a given mutex occur in a single total
- order. Each mutex acquisition ''reads the value written'' by the last mutex release.
-<p><!--para 14 -->
- An evaluation A carries a dependency <sup><a href="#note15"><b>15)</b></a></sup> to an evaluation B if:
-<!--page 37 -->
-<ul>
-<li>  the value of A is used as an operand of B, unless:
-<ul>
-<li> B is an invocation of the kill_dependency macro,
-<li> A is the left operand of a &amp;&amp; or || operator,
-<li> A is the left operand of a ? : operator, or
-<li> A is the left operand of a , operator;
-</ul>
-   or
-<li>  A writes a scalar object or bit-field M, B reads from M the value written by A, and A
- is sequenced before B, or
-<li>  for some evaluation X, A carries a dependency to X and X carries a dependency to B.
-</ul>
-<p><!--para 15 -->
- An evaluation A is dependency-ordered before<sup><a href="#note16"><b>16)</b></a></sup> an evaluation B if:
-<ul>
-<li>  A performs a release operation on an atomic object M, and B performs a consume
- operation on M and reads a value written by any side effect in the release sequence
- headed by A, or
-<li>  for some evaluation X, A is dependency-ordered before X and X carries a
- dependency to B.
-</ul>
-<p><!--para 16 -->
- An evaluation A inter-thread happens before an evaluation B if A synchronizes with B, A
- is dependency-ordered before B, or, for some evaluation X:
-<ul>
-<li>  A synchronizes with X and X is sequenced before B,
-<li>  A is sequenced before X and X inter-thread happens before B, or
-<li>  A inter-thread happens before X and X inter-thread happens before B.
-</ul>
-<p><!--para 17 -->
- NOTE 7 The ''inter-thread happens before'' relation describes arbitrary concatenations of ''sequenced
- before'', ''synchronizes with'', and ''dependency-ordered before'' relationships, with two exceptions. The
- first exception is that a concatenation is not permitted to end with ''dependency-ordered before'' followed
- by ''sequenced before''. The reason for this limitation is that a consume operation participating in a
- ''dependency-ordered before'' relationship provides ordering only with respect to operations to which this
- consume operation actually carries a dependency. The reason that this limitation applies only to the end of
- such a concatenation is that any subsequent release operation will provide the required ordering for a prior
- consume operation. The second exception is that a concatenation is not permitted to consist entirely of
- ''sequenced before''. The reasons for this limitation are (1) to permit ''inter-thread happens before'' to be
- transitively closed and (2) the ''happens before'' relation, defined below, provides for relationships
- consisting entirely of ''sequenced before''.
-<p><!--para 18 -->
- An evaluation A happens before an evaluation B if A is sequenced before B or A inter-
- thread happens before B.
-<!--page 38 -->
-<p><!--para 19 -->
- A visible side effect A on an object M with respect to a value computation B of M
- satisfies the conditions:
-<ul>
-<li>  A happens before B, and
-<li>  there is no other side effect X to M such that A happens before X and X happens
-   before B.
-</ul>
- The value of a non-atomic scalar object M, as determined by evaluation B, shall be the
- value stored by the visible side effect A.
-<p><!--para 20 -->
- NOTE 8 If there is ambiguity about which side effect to a non-atomic object is visible, then there is a data
- race and the behavior is undefined.
-<p><!--para 21 -->
- NOTE 9 This states that operations on ordinary variables are not visibly reordered. This is not actually
- detectable without data races, but it is necessary to ensure that data races, as defined here, and with suitable
- restrictions on the use of atomics, correspond to data races in a simple interleaved (sequentially consistent)
- execution.
-<p><!--para 22 -->
- The visible sequence of side effects on an atomic object M, with respect to a value
- computation B of M, is a maximal contiguous sub-sequence of side effects in the
- modification order of M, where the first side effect is visible with respect to B, and for
- every subsequent side effect, it is not the case that B happens before it. The value of an
- atomic object M, as determined by evaluation B, shall be the value stored by some
- operation in the visible sequence of M with respect to B. Furthermore, if a value
- computation A of an atomic object M happens before a value computation B of M, and
- the value computed by A corresponds to the value stored by side effect X, then the value
- computed by B shall either equal the value computed by A, or be the value stored by side
- effect Y , where Y follows X in the modification order of M.
-<p><!--para 23 -->
- NOTE 10 This effectively disallows compiler reordering of atomic operations to a single object, even if
- both operations are ''relaxed'' loads. By doing so, we effectively make the ''cache coherence'' guarantee
- provided by most hardware available to C atomic operations.
-<p><!--para 24 -->
- NOTE 11 The visible sequence depends on the ''happens before'' relation, which in turn depends on the
- values observed by loads of atomics, which we are restricting here. The intended reading is that there must
- exist an association of atomic loads with modifications they observe that, together with suitably chosen
- modification orders and the ''happens before'' relation derived as described above, satisfy the resulting
- constraints as imposed here.
-<p><!--para 25 -->
- The execution of a program contains a data race if it contains two conflicting actions in
- different threads, at least one of which is not atomic, and neither happens before the
- other. Any such data race results in undefined behavior.
-<p><!--para 26 -->
- NOTE 12 It can be shown that programs that correctly use simple mutexes and
- memory_order_seq_cst operations to prevent all data races, and use no other synchronization
- operations, behave as though the operations executed by their constituent threads were simply interleaved,
- with each value computation of an object being the last value stored in that interleaving. This is normally
- referred to as ''sequential consistency''. However, this applies only to data-race-free programs, and data-
- race-free programs cannot observe most program transformations that do not change single-threaded
- program semantics. In fact, most single-threaded program transformations continue to be allowed, since
- any program that behaves differently as a result must contain undefined behavior.
-<!--page 39 -->
-<p><!--para 27 -->
- NOTE 13 Compiler transformations that introduce assignments to a potentially shared memory location
- that would not be modified by the abstract machine are generally precluded by this standard, since such an
- assignment might overwrite another assignment by a different thread in cases in which an abstract machine
- execution would not have encountered a data race. This includes implementations of data member
- assignment that overwrite adjacent members in separate memory locations. We also generally preclude
- reordering of atomic loads in cases in which the atomics in question may alias, since this may violate the
- "visible sequence" rules.
-<p><!--para 28 -->
- NOTE 14 Transformations that introduce a speculative read of a potentially shared memory location may
- not preserve the semantics of the program as defined in this standard, since they potentially introduce a data
- race. However, they are typically valid in the context of an optimizing compiler that targets a specific
- machine with well-defined semantics for data races. They would be invalid for a hypothetical machine that
- is not tolerant of races or provides hardware race detection.
-<!--page 40 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note14" href="#note14">14)</a> The execution can usually be viewed as an interleaving of all of the threads. However, some kinds of
- atomic operations, for example, allow executions inconsistent with a simple interleaving as described
- below.
-</small>
-<p><small><a name="note15" href="#note15">15)</a> The ''carries a dependency'' relation is a subset of the ''sequenced before'' relation, and is similarly
- strictly intra-thread.
-</small>
-<p><small><a name="note16" href="#note16">16)</a> The ''dependency-ordered before'' relation is analogous to the ''synchronizes with'' relation, but uses
- release/consume in place of release/acquire.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="5.2" href="#5.2">5.2 Environmental considerations</a></h3>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="5.2.1" href="#5.2.1">5.2.1 Character sets</a></h4>
-<p><!--para 1 -->
- Two sets of characters and their associated collating sequences shall be defined: the set in
- which source files are written (the source character set), and the set interpreted in the
- execution environment (the execution character set). Each set is further divided into a
- basic character set, whose contents are given by this subclause, and a set of zero or more
- locale-specific members (which are not members of the basic character set) called
- extended characters. The combined set is also called the extended character set. The
- values of the members of the execution character set are implementation-defined.
-<p><!--para 2 -->
- 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.
-<p><!--para 3 -->
- Both the basic source and basic execution character sets shall have the following
- members: the 26 uppercase letters of the Latin alphabet
-<pre>
-         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
-</pre>
- the 26 lowercase letters of the Latin alphabet
-<pre>
-         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
-</pre>
- the 10 decimal digits
-<pre>
-         0    1   2      3   4   5    6    7    8    9
-</pre>
- the following 29 graphic characters
-<pre>
-         !    "   #      %   &amp;   '    (    )    *    +    ,    -   .    /    :
-         ;    &lt;   =      &gt;   ?   [    \    ]    ^    _    {    |   }    ~
-</pre>
- the space character, and control characters representing horizontal tab, vertical tab, and
- form feed. The representation of each member of the source and execution basic
- character sets shall fit in a byte. 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 International Standard treats such an end-of-line indicator as if it
- were a single new-line character. In the basic 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 an identifier, a character
- constant, a string literal, a header name, a comment, or a preprocessing token that is never
-<!--page 41 -->
- converted to a token), the behavior is undefined.
-<p><!--para 4 -->
- A letter is an uppercase letter or a lowercase letter as defined above; in this International
- Standard the term does not include other characters that are letters in other alphabets.
-<p><!--para 5 -->
- The universal character name construct provides a way to name other characters.
-<p><b> Forward references</b>: universal character names (<a href="#6.4.3">6.4.3</a>), character constants (<a href="#6.4.4.4">6.4.4.4</a>),
- preprocessing directives (<a href="#6.10">6.10</a>), string literals (<a href="#6.4.5">6.4.5</a>), comments (<a href="#6.4.9">6.4.9</a>), string (<a href="#7.1.1">7.1.1</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.2.1.1" href="#5.2.1.1">5.2.1.1 Trigraph sequences</a></h5>
-<p><!--para 1 -->
- Before any other processing takes place, each occurrence of one of the following
- sequences of three characters (called trigraph sequences<sup><a href="#note17"><b>17)</b></a></sup>) is replaced with the
- corresponding single character.
-<pre>
-        ??=      #                       ??)      ]                       ??!     |
-        ??(      [                       ??'      ^                       ??&gt;     }
-        ??/      \                       ??&lt;      {                       ??-     ~
-</pre>
- No other trigraph sequences exist. Each ? that does not begin one of the trigraphs listed
- above is not changed.
-<p><!--para 2 -->
- EXAMPLE 1
-<pre>
-           ??=define arraycheck(a, b) a??(b??) ??!??! b??(a??)
-</pre>
- becomes
-<pre>
-           #define arraycheck(a, b) a[b] || b[a]
-</pre>
-<p><!--para 3 -->
- EXAMPLE 2      The following source line
-<pre>
-           printf("Eh???/n");
-</pre>
- becomes (after replacement of the trigraph sequence ??/)
-<pre>
-           printf("Eh?\n");
-</pre>
-
-<p><b>Footnotes</b>
-<p><small><a name="note17" href="#note17">17)</a> The trigraph sequences enable the input of characters that are not defined in the Invariant Code Set as
- described in ISO/IEC 646, which is a subset of the seven-bit US ASCII code set.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.2.1.2" href="#5.2.1.2">5.2.1.2 Multibyte characters</a></h5>
-<p><!--para 1 -->
- 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:
-<ul>
-<li>  The basic character set shall be present and each character shall be encoded as a
- single byte.
-<li>  The presence, meaning, and representation of any additional members is locale-
- specific.
-<!--page 42 -->
-<li>  A multibyte character set may have a state-dependent encoding, wherein each
- sequence of multibyte characters begins in an initial shift state and enters other
- locale-specific 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.
-<li>  A byte with all bits zero shall be interpreted as a null character independent of shift
- state. Such a byte shall not occur as part of any other multibyte character.
-</ul>
-<p><!--para 2 -->
- For source files, the following shall hold:
-<ul>
-<li>  An identifier, comment, string literal, character constant, or header name shall begin
- and end in the initial shift state.
-<li>  An identifier, comment, string literal, character constant, or header name shall consist
- of a sequence of valid multibyte characters.
-</ul>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="5.2.2" href="#5.2.2">5.2.2 Character display semantics</a></h4>
-<p><!--para 1 -->
- 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 printing 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 writing is locale-specific. If the active
- position is at the final position of a line (if there is one), the behavior of the display device
- is unspecified.
-<p><!--para 2 -->
- Alphabetic escape sequences representing nongraphic characters in the execution
- character set are intended to produce actions on display devices as follows:
- \a (alert) Produces an audible or visible alert without changing the active position.
- \b (backspace) Moves the active position to the previous position on the current line. If
-<pre>
-    the active position is at the initial position of a line, the behavior of the display
-    device is unspecified.
-</pre>
- \f ( form feed) Moves the active position to the initial position at the start of the next
-<pre>
-    logical page.
-</pre>
- \n (new line) Moves the active position to the initial position of the next line.
- \r (carriage return) Moves the active position to the initial position of the current line.
- \t (horizontal tab) Moves the active position to the next horizontal tabulation position
-<pre>
-    on the current line. If the active position is at or past the last defined horizontal
-    tabulation position, the behavior of the display device is unspecified.
-</pre>
- \v (vertical tab) Moves the active position to the initial position of the next vertical
-<!--page 43 -->
-<pre>
-    tabulation position. If the active position is at or past the last defined vertical
-      tabulation position, the behavior of the display device is unspecified.
-</pre>
-<p><!--para 3 -->
- 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
- International Standard.
-<p><b> Forward references</b>: the isprint function (<a href="#7.4.1.8">7.4.1.8</a>), the fputc function (<a href="#7.21.7.3">7.21.7.3</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="5.2.3" href="#5.2.3">5.2.3 Signals and interrupts</a></h4>
-<p><!--para 1 -->
- 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 compose the executable representation of a function) on a
- per-invocation basis.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="5.2.4" href="#5.2.4">5.2.4 Environmental limits</a></h4>
-<p><!--para 1 -->
- Both the translation and execution environments constrain the implementation of
- language translators and libraries. The following summarizes the language-related
- environmental limits on a conforming implementation; the library-related limits are
- discussed in clause 7.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.2.4.1" href="#5.2.4.1">5.2.4.1 Translation limits</a></h5>
-<p><!--para 1 -->
- 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:<sup><a href="#note18"><b>18)</b></a></sup>
-<ul>
-<li>  127 nesting levels of blocks
-<li>  63 nesting levels of conditional inclusion
-<li>  12 pointer, array, and function declarators (in any combinations) modifying an
- arithmetic, structure, union, or void type in a declaration
-<li>  63 nesting levels of parenthesized declarators within a full declarator
-<li>  63 nesting levels of parenthesized expressions within a full expression
-<li>  63 significant initial characters in an internal identifier or a macro name (each
- universal character name or extended source character is considered a single
- character)
-<li>  31 significant initial characters in an external identifier (each universal character name
- specifying a short identifier of 0000FFFF or less is considered 6 characters, each
-<!--page 44 -->
-<pre>
-    universal character name specifying a short identifier of 00010000 or more is
-    considered 10 characters, and each extended source character is considered the same
-    number of characters as the corresponding universal character name, if any)<sup><a href="#note19"><b>19)</b></a></sup>
-</pre>
-<li>  4095 external identifiers in one translation unit
-<li>  511 identifiers with block scope declared in one block
-<li>  4095 macro identifiers simultaneously defined in one preprocessing translation unit
-<li>  127 parameters in one function definition
-<li>  127 arguments in one function call
-<li>  127 parameters in one macro definition
-<li>  127 arguments in one macro invocation
-<li>  4095 characters in a logical source line
-<li>  4095 characters in a string literal (after concatenation)
-<li>  65535 bytes in an object (in a hosted environment only)
-<li>  15 nesting levels for #included files
-<li>  1023 case labels for a switch statement (excluding those for any nested switch
- statements)
-<li>  1023 members in a single structure or union
-<li>  1023 enumeration constants in a single enumeration
-<li>  63 levels of nested structure or union definitions in a single struct-declaration-list
-</ul>
-
-<p><b>Footnotes</b>
-<p><small><a name="note18" href="#note18">18)</a> Implementations should avoid imposing fixed translation limits whenever possible.
-</small>
-<p><small><a name="note19" href="#note19">19)</a> See ''future language directions'' (<a href="#6.11.3">6.11.3</a>).
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.2.4.2" href="#5.2.4.2">5.2.4.2 Numerical limits</a></h5>
-<p><!--para 1 -->
- An implementation is required to document all the limits specified in this subclause,
- which are specified in the headers <a href="#7.10">&lt;limits.h&gt;</a> and <a href="#7.7">&lt;float.h&gt;</a>. Additional limits are
- specified in <a href="#7.20">&lt;stdint.h&gt;</a>.
-<p><b> Forward references</b>: integer types <a href="#7.20">&lt;stdint.h&gt;</a> (<a href="#7.20">7.20</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.2.4.2.1" href="#5.2.4.2.1">5.2.4.2.1 Sizes of integer types &lt;limits.h&gt;</a></h5>
-<p><!--para 1 -->
- The values given below shall be replaced by constant expressions suitable for use in #if
- preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the
- following shall be replaced by expressions that have the same type as would an
- expression that is an object of the corresponding type converted according to the integer
- promotions. Their implementation-defined values shall be equal or greater in magnitude
-<!--page 45 -->
- (absolute value) to those shown, with the same sign.
-<ul>
-<li>  number of bits for smallest object that is not a bit-field (byte)
- CHAR_BIT                                            8
-<li>  minimum value for an object of type signed char
- SCHAR_MIN                                -127 // -(27 - 1)
-<li>  maximum value for an object of type signed char
- SCHAR_MAX                                +127 // 27 - 1
-<li>  maximum value for an object of type unsigned char
- UCHAR_MAX                                 255 // 28 - 1
-<li>  minimum value for an object of type char
- CHAR_MIN                               see below
-<li>  maximum value for an object of type char
- CHAR_MAX                              see below
-<li>  maximum number of bytes in a multibyte character, for any supported locale
- MB_LEN_MAX                                    1
-<li>  minimum value for an object of type short int
- SHRT_MIN                               -32767 // -(215 - 1)
-<li>  maximum value for an object of type short int
- SHRT_MAX                               +32767 // 215 - 1
-<li>  maximum value for an object of type unsigned short int
- USHRT_MAX                               65535 // 216 - 1
-<li>  minimum value for an object of type int
- INT_MIN                                 -32767 // -(215 - 1)
-<li>  maximum value for an object of type int
- INT_MAX                                +32767 // 215 - 1
-<li>  maximum value for an object of type unsigned int
- UINT_MAX                                65535 // 216 - 1
-<li>  minimum value for an object of type long int
- LONG_MIN                         -2147483647 // -(231 - 1)
-<li>  maximum value for an object of type long int
- LONG_MAX                         +2147483647 // 231 - 1
-<li>  maximum value for an object of type unsigned long int
- ULONG_MAX                         4294967295 // 232 - 1
-<!--page 46 -->
-<li>  minimum value for an object of type long long int
- LLONG_MIN          -9223372036854775807 // -(263 - 1)
-<li>  maximum value for an object of type long long int
- LLONG_MAX          +9223372036854775807 // 263 - 1
-<li>  maximum value for an object of type unsigned long long int
- ULLONG_MAX         18446744073709551615 // 264 - 1
-</ul>
-<p><!--para 2 -->
- If the value of an object of type char is treated as a signed integer 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. Otherwise, the value of
- CHAR_MIN shall be 0 and the value of CHAR_MAX shall be the same as that of
- UCHAR_MAX.<sup><a href="#note20"><b>20)</b></a></sup> The value UCHAR_MAX shall equal 2CHAR_BIT - 1.
-<p><b> Forward references</b>: representations of types (<a href="#6.2.6">6.2.6</a>), conditional inclusion (<a href="#6.10.1">6.10.1</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note20" href="#note20">20)</a> See <a href="#6.2.5">6.2.5</a>.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="5.2.4.2.2" href="#5.2.4.2.2">5.2.4.2.2 Characteristics of floating types &lt;float.h&gt;</a></h5>
-<p><!--para 1 -->
- 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.<sup><a href="#note21"><b>21)</b></a></sup> The following parameters are used to
- define the model for each floating-point type:
-<pre>
-        s          sign ((+-)1)
-        b          base or radix of exponent representation (an integer &gt; 1)
-        e          exponent (an integer between a minimum emin and a maximum emax )
-        p          precision (the number of base-b digits in the significand)
-         fk        nonnegative integers less than b (the significand digits)
-</pre>
-<p><!--para 2 -->
- A floating-point number (x) is defined by the following model:
-<pre>
-                    p
-        x = sb e   (Sum) f k b-k ,
-                   k=1
-                                 emin &lt;= e &lt;= emax
-</pre>
-<p><!--para 3 -->
- In addition to normalized floating-point numbers ( f 1 &gt; 0 if x != 0), floating types may be
- able to contain other kinds of floating-point numbers, such as subnormal floating-point
- numbers (x != 0, e = emin , f 1 = 0) and unnormalized floating-point numbers (x != 0,
- e &gt; emin , f 1 = 0), and values that are not floating-point numbers, such as infinities and
- NaNs. A NaN is an encoding signifying Not-a-Number. A quiet NaN propagates
- through almost every arithmetic operation without raising a floating-point exception; a
- signaling NaN generally raises a floating-point exception when occurring as an
-<!--page 47 -->
- arithmetic operand.<sup><a href="#note22"><b>22)</b></a></sup>
-<p><!--para 4 -->
- An implementation may give zero and values that are not floating-point numbers (such as
- infinities and NaNs) a sign or may leave them unsigned. Wherever such values are
- unsigned, any requirement in this International Standard to retrieve the sign shall produce
- an unspecified sign, and any requirement to set the sign shall be ignored.
-<p><!--para 5 -->
- The minimum range of representable values for a floating type is the most negative finite
- floating-point number representable in that type through the most positive finite floating-
- point number representable in that type. In addition, if negative infinity is representable
- in a type, the range of that type is extended to all negative real numbers; likewise, if
- positive infinity is representable in a type, the range of that type is extended to all positive
- real numbers.
-<p><!--para 6 -->
- The accuracy of the floating-point operations (+, -, *, /) and of the library functions in
- <a href="#7.12">&lt;math.h&gt;</a> and <a href="#7.3">&lt;complex.h&gt;</a> that return floating-point results is implementation-
- defined, as is the accuracy of the conversion between floating-point internal
- representations and string representations performed by the library functions in
- <a href="#7.21">&lt;stdio.h&gt;</a>, <a href="#7.22">&lt;stdlib.h&gt;</a>, and <a href="#7.28">&lt;wchar.h&gt;</a>. The implementation may state that the
- accuracy is unknown.
-<p><!--para 7 -->
- All integer values in the <a href="#7.7">&lt;float.h&gt;</a> header, except FLT_ROUNDS, shall be constant
- expressions suitable for use in #if preprocessing directives; all floating values shall be
- constant expressions. All except DECIMAL_DIG, FLT_EVAL_METHOD, 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_EVAL_METHOD and
- FLT_ROUNDS.
-<p><!--para 8 -->
- The rounding mode for floating-point addition is characterized by the implementation-
- defined value of FLT_ROUNDS:<sup><a href="#note23"><b>23)</b></a></sup>
-<pre>
-       -1      indeterminable
-        0      toward zero
-        1      to nearest
-        2      toward positive infinity
-        3      toward negative infinity
-</pre>
- All other values for FLT_ROUNDS characterize implementation-defined rounding
- behavior.
-<!--page 48 -->
-<p><!--para 9 -->
- Except for assignment and cast (which remove all extra range and precision), the values
- yielded by operators with floating operands and values subject to the usual arithmetic
- conversions and of floating constants are evaluated to a format whose range and precision
- may be greater than required by the type. The use of evaluation formats is characterized
- by the implementation-defined value of FLT_EVAL_METHOD:<sup><a href="#note24"><b>24)</b></a></sup>
-<pre>
-        -1         indeterminable;
-          0        evaluate all operations and constants just to the range and precision of the
-                   type;
-          1        evaluate operations and constants of type float and double to the
-                   range and precision of the double type, evaluate long double
-                   operations and constants to the range and precision of the long double
-                   type;
-          2        evaluate all operations and constants to the range and precision of the
-                   long double type.
-</pre>
- All other negative values for FLT_EVAL_METHOD characterize implementation-defined
- behavior.
-<p><!--para 10 -->
- The presence or absence of subnormal numbers is characterized by the implementation-
- defined     values     of    FLT_HAS_SUBNORM,          DBL_HAS_SUBNORM,           and
- LDBL_HAS_SUBNORM:
-<pre>
-        -1       indeterminable<sup><a href="#note25"><b>25)</b></a></sup>
-         0       absent<sup><a href="#note26"><b>26)</b></a></sup> (type does not support subnormal numbers)
-         1       present (type does support subnormal numbers)
-</pre>
-<p><!--para 11 -->
- The values given in the following list shall be replaced by constant expressions with
- implementation-defined values that are greater or equal in magnitude (absolute value) to
- those shown, with the same sign:
-<ul>
-<li>  radix of exponent representation, b
- FLT_RADIX                                                    2
-<!--page 49 -->
-<li>  number of base-FLT_RADIX digits in the floating-point significand, p
-  FLT_MANT_DIG
-  DBL_MANT_DIG
-  LDBL_MANT_DIG
-<li>  number of decimal digits, n, such that any floating-point number with p radix b digits
- can be rounded to a floating-point number with n decimal digits and back again
- without change to the value,
-<pre>
-      { p log10 b        if b is a power of 10
-      {
-      { [^1 + p log10 b^] otherwise
-</pre>
-  FLT_DECIMAL_DIG                                   6
-  DBL_DECIMAL_DIG                                  10
-  LDBL_DECIMAL_DIG                                 10
-<li>  number of decimal digits, n, such that any floating-point number in the widest
- supported floating type with pmax radix b digits can be rounded to a floating-point
- number with n decimal digits and back again without change to the value,
-<pre>
-      { pmax log10 b       if b is a power of 10
-      {
-      { [^1 + pmax log10 b^] otherwise
-</pre>
-  DECIMAL_DIG                                     10
-<li>  number of decimal digits, q, such that any floating-point number with q decimal digits
- can be rounded into a floating-point number with p radix b digits and back again
- without change to the q decimal digits,
-<pre>
-      { p log10 b          if b is a power of 10
-      {
-      { [_( p - 1) log10 b_] otherwise
-</pre>
-  FLT_DIG                                          6
-  DBL_DIG                                         10
-  LDBL_DIG                                        10
-<li>  minimum negative integer such that FLT_RADIX raised to one less than that power is
- a normalized floating-point number, emin
-  FLT_MIN_EXP
-  DBL_MIN_EXP
-  LDBL_MIN_EXP
-<!--page 50 -->
-<li>  minimum negative integer such that 10 raised to that power is in the range of
- normalized floating-point numbers, [^log10 b emin -1 ^]
-<pre>
-                                   [                  ]
-</pre>
- FLT_MIN_10_EXP                                 -37
- DBL_MIN_10_EXP                                 -37
- LDBL_MIN_10_EXP                                -37
-<li>  maximum integer such that FLT_RADIX raised to one less than that power is a
- representable finite floating-point number, emax
-<pre>
-    FLT_MAX_EXP
-    DBL_MAX_EXP
-    LDBL_MAX_EXP
-</pre>
-<li>  maximum integer such that 10 raised to that power is in the range of representable
- finite floating-point numbers, [_log10 ((1 - b- p )b emax )_]
-<pre>
-    FLT_MAX_10_EXP                               +37
-    DBL_MAX_10_EXP                               +37
-    LDBL_MAX_10_EXP                              +37
-</pre>
-</ul>
-<p><!--para 12 -->
- The values given in the following list shall be replaced by constant expressions with
- implementation-defined values that are greater than or equal to those shown:
-<ul>
-<li>  maximum representable finite floating-point number, (1 - b- p )b emax
-<pre>
-    FLT_MAX                                   1E+37
-    DBL_MAX                                   1E+37
-    LDBL_MAX                                  1E+37
-</pre>
-</ul>
-<p><!--para 13 -->
- The values given in the following list shall be replaced by constant expressions with
- implementation-defined (positive) values that are less than or equal to those shown:
-<ul>
-<li>  the difference between 1 and the least value greater than 1 that is representable in the
- given floating point type, b1- p
-<pre>
-    FLT_EPSILON                                1E-5
-    DBL_EPSILON                                1E-9
-    LDBL_EPSILON                               1E-9
-</pre>
-<li>  minimum normalized positive floating-point number, b emin -1
-<!--page 51 -->
-<pre>
-    FLT_MIN                                   1E-37
-    DBL_MIN                                   1E-37
-    LDBL_MIN                                  1E-37
-</pre>
-<li>  minimum positive floating-point number<sup><a href="#note27"><b>27)</b></a></sup>
-   FLT_TRUE_MIN                                       1E-37
-   DBL_TRUE_MIN                                       1E-37
-   LDBL_TRUE_MIN                                      1E-37
-</ul>
-<p><b>Recommended practice</b>
-<p><!--para 14 -->
- Conversion from (at least) double to decimal with DECIMAL_DIG digits and back
- should be the identity function.
-<p><!--para 15 -->
- EXAMPLE 1 The following describes an artificial floating-point representation that meets the minimum
- requirements of this International Standard, and the appropriate values in a <a href="#7.7">&lt;float.h&gt;</a> header for type
- float:
-<pre>
-                    6
-       x = s16e    (Sum) f k 16-k ,
-                   k=1
-                                   -31 &lt;= e &lt;= +32
-</pre>
-<pre>
-         FLT_RADIX                                    16
-         FLT_MANT_DIG                                  6
-         FLT_EPSILON                     9.53674316E-07F
-         FLT_DECIMAL_DIG                               9
-         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
-</pre>
-<p><!--para 16 -->
- EXAMPLE 2 The following describes floating-point representations that also meet the requirements for
- single-precision and double-precision numbers in IEC 60559,<sup><a href="#note28"><b>28)</b></a></sup> and the appropriate values in a
- <a href="#7.7">&lt;float.h&gt;</a> header for types float and double:
-<pre>
-                   24
-       x f = s2e   (Sum) f k 2-k ,
-                   k=1
-                                  -125 &lt;= e &lt;= +128
-</pre>
-<pre>
-                   53
-       x d = s2e   (Sum) f k 2-k ,
-                   k=1
-                                  -1021 &lt;= e &lt;= +1024
-</pre>
-<pre>
-         FLT_RADIX                                     2
-         DECIMAL_DIG                                  17
-         FLT_MANT_DIG                                 24
-         FLT_EPSILON                     1.19209290E-07F // decimal constant
-         FLT_EPSILON                            0X1P-23F // hex constant
-         FLT_DECIMAL_DIG                               9
-</pre>
-<!--page 52 -->
-<pre>
-         FLT_DIG                             6
-         FLT_MIN_EXP                      -125
-         FLT_MIN               1.17549435E-38F               //   decimal constant
-         FLT_MIN                     0X1P-126F               //   hex constant
-         FLT_TRUE_MIN          1.40129846E-45F               //   decimal constant
-         FLT_TRUE_MIN                0X1P-149F               //   hex constant
-         FLT_HAS_SUBNORM                     1
-         FLT_MIN_10_EXP                    -37
-         FLT_MAX_EXP                      +128
-         FLT_MAX               3.40282347E+38F               // decimal constant
-         FLT_MAX               0X1.fffffeP127F               // hex constant
-         FLT_MAX_10_EXP                    +38
-         DBL_MANT_DIG                       53
-         DBL_EPSILON    2.2204460492503131E-16               // decimal constant
-         DBL_EPSILON                   0X1P-52               // hex constant
-         DBL_DECIMAL_DIG                    17
-         DBL_DIG                            15
-         DBL_MIN_EXP                     -1021
-         DBL_MIN      2.2250738585072014E-308                //   decimal constant
-         DBL_MIN                     0X1P-1022               //   hex constant
-         DBL_TRUE_MIN 4.9406564584124654E-324                //   decimal constant
-         DBL_TRUE_MIN                0X1P-1074               //   hex constant
-         DBL_HAS_SUBNORM                     1
-         DBL_MIN_10_EXP                   -307
-         DBL_MAX_EXP                     +1024
-         DBL_MAX      1.7976931348623157E+308                // decimal constant
-         DBL_MAX        0X1.fffffffffffffP1023               // hex constant
-         DBL_MAX_10_EXP                   +308
-</pre>
- If a type wider than double were supported, then DECIMAL_DIG would be greater than 17. For
- example, if the widest type were to use the minimal-width IEC 60559 double-extended format (64 bits of
- precision), then DECIMAL_DIG would be 21.
-<p><b> Forward references</b>:        conditional inclusion (<a href="#6.10.1">6.10.1</a>), complex arithmetic
- <a href="#7.3">&lt;complex.h&gt;</a> (<a href="#7.3">7.3</a>), extended multibyte and wide character utilities <a href="#7.28">&lt;wchar.h&gt;</a>
- (<a href="#7.28">7.28</a>), floating-point environment <a href="#7.6">&lt;fenv.h&gt;</a> (<a href="#7.6">7.6</a>), general utilities <a href="#7.22">&lt;stdlib.h&gt;</a>
- (<a href="#7.22">7.22</a>), input/output <a href="#7.21">&lt;stdio.h&gt;</a> (<a href="#7.21">7.21</a>), mathematics <a href="#7.12">&lt;math.h&gt;</a> (<a href="#7.12">7.12</a>).
-<!--page 53 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note21" href="#note21">21)</a> The floating-point model is intended to clarify the description of each floating-point characteristic and
- does not require the floating-point arithmetic of the implementation to be identical.
-</small>
-<p><small><a name="note22" href="#note22">22)</a> IEC 60559:1989 specifies quiet and signaling NaNs. For implementations that do not support
- IEC 60559:1989, the terms quiet NaN and signaling NaN are intended to apply to encodings with
- similar behavior.
-</small>
-<p><small><a name="note23" href="#note23">23)</a> Evaluation of FLT_ROUNDS correctly reflects any execution-time change of rounding mode through
- the function fesetround in <a href="#7.6">&lt;fenv.h&gt;</a>.
-</small>
-<p><small><a name="note24" href="#note24">24)</a> The evaluation method determines evaluation formats of expressions involving all floating types, not
- just real types. For example, if FLT_EVAL_METHOD is 1, then the product of two float
- _Complex operands is represented in the double _Complex format, and its parts are evaluated to
- double.
-</small>
-<p><small><a name="note25" href="#note25">25)</a> Characterization as indeterminable is intended if floating-point operations do not consistently interpret
- subnormal representations as zero, nor as nonzero.
-</small>
-<p><small><a name="note26" href="#note26">26)</a> Characterization as absent is intended if no floating-point operations produce subnormal results from
- non-subnormal inputs, even if the type format includes representations of subnormal numbers.
-</small>
-<p><small><a name="note27" href="#note27">27)</a> If the presence or absence of subnormal numbers is indeterminable, then the value is intended to be a
- positive number no greater than the minimum normalized positive number for the type.
-</small>
-<p><small><a name="note28" href="#note28">28)</a> The floating-point model in that standard sums powers of b from zero, so the values of the exponent
- limits are one less than shown here.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h2><a name="6" href="#6">6. Language</a></h2>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="6.1" href="#6.1">6.1 Notation</a></h3>
-<p><!--para 1 -->
- In the syntax notation used in this clause, 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 subscript ''opt'', so that
-<pre>
-          { expression<sub>opt</sub> }
-</pre>
- indicates an optional expression enclosed in braces.
-<p><!--para 2 -->
- When syntactic categories are referred to in the main text, they are not italicized and
- words are separated by spaces instead of hyphens.
-<p><!--para 3 -->
- A summary of the language syntax is given in <a href="#A">annex A</a>.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="6.2" href="#6.2">6.2 Concepts</a></h3>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.2.1" href="#6.2.1">6.2.1 Scopes of identifiers</a></h4>
-<p><!--para 1 -->
- An identifier can denote an object; a function; a tag or a member of a structure, union, or
- enumeration; a typedef name; a label name; a macro name; or a macro parameter. The
- same identifier can denote different entities at different points in the program. A member
- of an enumeration is called an enumeration constant. Macro names and macro
- parameters are not considered further here, because prior to the semantic phase of
- program translation any occurrences of macro names in the source file are replaced by the
- preprocessing token sequences that constitute their macro definitions.
-<p><!--para 2 -->
- For each different entity that an identifier designates, the identifier is visible (i.e., can be
- used) only within a region of program text called its scope. Different entities designated
- by the same identifier either have different scopes, or are in different name spaces. There
- are four kinds of scopes: function, file, block, and function prototype. (A function
- prototype is a declaration of a function that declares the types of its parameters.)
-<p><!--para 3 -->
- A label name is the only kind of identifier that has function scope. It can be used (in a
- goto statement) anywhere in the function in which it appears, and is declared implicitly
- by its syntactic appearance (followed by a : and a statement).
-<p><!--para 4 -->
- Every other identifier has scope determined by the placement of its declaration (in a
- declarator or type specifier). If the declarator or type specifier that declares the identifier
- appears outside of any block or list of parameters, the identifier has file scope, which
- terminates at the end of the translation unit. If the declarator or type specifier that
- declares the identifier appears inside a block or within the list of parameter declarations in
- a function definition, the identifier has block scope, which terminates at the end of the
- associated block. If the declarator or type specifier that declares the identifier appears
-<!--page 54 -->
- within the list of parameter declarations in a function prototype (not part of a function
- definition), the identifier has function prototype scope, which terminates at the end of the
- function declarator. If an identifier designates two different entities in the same name
- space, the scopes might overlap. If so, the scope of one entity (the inner scope) will end
- strictly before the scope of the other entity (the outer scope). Within the inner scope, the
- identifier designates the entity declared in the inner scope; the entity declared in the outer
- scope is hidden (and not visible) within the inner scope.
-<p><!--para 5 -->
- Unless explicitly stated otherwise, where this International Standard uses the term
- ''identifier'' to refer to some entity (as opposed to the syntactic construct), it refers to the
- entity in the relevant name space whose declaration is visible at the point the identifier
- occurs.
-<p><!--para 6 -->
- Two identifiers have the same scope if and only if their scopes terminate at the same
- point.
-<p><!--para 7 -->
- Structure, union, and enumeration tags have scope that begins just after the appearance of
- the tag in a type specifier that declares the tag. Each enumeration constant has scope that
- begins just after the appearance of its defining enumerator in an enumerator list. Any
- other identifier has scope that begins just after the completion of its declarator.
-<p><!--para 8 -->
- As a special case, a type name (which is not a declaration of an identifier) is considered to
- have a scope that begins just after the place within the type name where the omitted
- identifier would appear were it not omitted.
-<p><b> Forward references</b>: declarations (<a href="#6.7">6.7</a>), function calls (<a href="#6.5.2.2">6.5.2.2</a>), function definitions
- (<a href="#6.9.1">6.9.1</a>), identifiers (<a href="#6.4.2">6.4.2</a>), macro replacement (<a href="#6.10.3">6.10.3</a>), name spaces of identifiers (<a href="#6.2.3">6.2.3</a>),
- source file inclusion (<a href="#6.10.2">6.10.2</a>), statements (<a href="#6.8">6.8</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.2.2" href="#6.2.2">6.2.2 Linkages of identifiers</a></h4>
-<p><!--para 1 -->
- An identifier declared in different scopes or in the same scope more than once can be
- made to refer to the same object or function by a process called linkage.<sup><a href="#note29"><b>29)</b></a></sup> There are
- three kinds of linkage: external, internal, and none.
-<p><!--para 2 -->
- In the set of translation units and libraries that constitutes an entire program, each
- declaration of a particular identifier with external linkage denotes the same object or
- function. Within one translation unit, each declaration of an identifier with internal
- linkage denotes the same object or function. Each declaration of an identifier with no
- linkage denotes a unique entity.
-<p><!--para 3 -->
- If the declaration of a file scope identifier for an object or a function contains the storage-
- class specifier static, the identifier has internal linkage.<sup><a href="#note30"><b>30)</b></a></sup>
-<!--page 55 -->
-<p><!--para 4 -->
- For an identifier declared with the storage-class specifier extern in a scope in which a
- prior declaration of that identifier is visible,<sup><a href="#note31"><b>31)</b></a></sup> if the prior declaration specifies internal or
- external linkage, the linkage of the identifier at the later declaration is the same as the
- linkage specified at the prior declaration. If no prior declaration is visible, or if the prior
- declaration specifies no linkage, then the identifier has external linkage.
-<p><!--para 5 -->
- If the declaration of an identifier for a function has no storage-class specifier, its linkage
- is determined exactly as if it were declared with the storage-class specifier extern. If
- the declaration of an identifier for an object has file scope and no storage-class specifier,
- its linkage is external.
-<p><!--para 6 -->
- The following identifiers have no linkage: an identifier declared to be anything other than
- an object or a function; an identifier declared to be a function parameter; a block scope
- identifier for an object declared without the storage-class specifier extern.
-<p><!--para 7 -->
- If, within a translation unit, the same identifier appears with both internal and external
- linkage, the behavior is undefined.
-<p><b> Forward references</b>: declarations (<a href="#6.7">6.7</a>), expressions (<a href="#6.5">6.5</a>), external definitions (<a href="#6.9">6.9</a>),
- statements (<a href="#6.8">6.8</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note29" href="#note29">29)</a> There is no linkage between different identifiers.
-</small>
-<p><small><a name="note30" href="#note30">30)</a> A function declaration can contain the storage-class specifier static only if it is at file scope; see
- <a href="#6.7.1">6.7.1</a>.
-</small>
-<p><small><a name="note31" href="#note31">31)</a> As specified in <a href="#6.2.1">6.2.1</a>, the later declaration might hide the prior declaration.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.2.3" href="#6.2.3">6.2.3 Name spaces of identifiers</a></h4>
-<p><!--para 1 -->
- If more than one declaration of a particular identifier is visible at any point in a
- translation unit, the syntactic context disambiguates uses that refer to different entities.
- Thus, there are separate name spaces for various categories of identifiers, as follows:
-<ul>
-<li>  label names (disambiguated by the syntax of the label declaration and use);
-<li>  the tags of structures, unions, and enumerations (disambiguated by following any<sup><a href="#note32"><b>32)</b></a></sup>
- of the keywords struct, union, or enum);
-<li>  the members of structures or unions; each structure or union has a separate name
- space for its members (disambiguated by the type of the expression used to access the
- member via the . or -&gt; operator);
-<li>  all other identifiers, called ordinary identifiers (declared in ordinary declarators or as
- enumeration constants).
-</ul>
-<p><b> Forward references</b>: enumeration specifiers (<a href="#6.7.2.2">6.7.2.2</a>), labeled statements (<a href="#6.8.1">6.8.1</a>),
- structure and union specifiers (<a href="#6.7.2.1">6.7.2.1</a>), structure and union members (<a href="#6.5.2.3">6.5.2.3</a>), tags
- (<a href="#6.7.2.3">6.7.2.3</a>), the goto statement (<a href="#6.8.6.1">6.8.6.1</a>).
-<!--page 56 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note32" href="#note32">32)</a> There is only one name space for tags even though three are possible.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.2.4" href="#6.2.4">6.2.4 Storage durations of objects</a></h4>
-<p><!--para 1 -->
- An object has a storage duration that determines its lifetime. There are four storage
- durations: static, thread, automatic, and allocated. Allocated storage is described in
- <a href="#7.22.3">7.22.3</a>.
-<p><!--para 2 -->
- The lifetime of an object is the portion of program execution during which storage is
- guaranteed to be reserved for it. An object exists, has a constant address,<sup><a href="#note33"><b>33)</b></a></sup> and retains
- its last-stored value throughout its lifetime.<sup><a href="#note34"><b>34)</b></a></sup> If an object is referred to outside of its
- lifetime, the behavior is undefined. The value of a pointer becomes indeterminate when
- the object it points to (or just past) reaches the end of its lifetime.
-<p><!--para 3 -->
- An object whose identifier is declared without the storage-class specifier
- _Thread_local, and either with external or internal linkage or with the storage-class
- specifier static, has static storage duration. Its lifetime is the entire execution of the
- program and its stored value is initialized only once, prior to program startup.
-<p><!--para 4 -->
- An object whose identifier is declared with the storage-class specifier _Thread_local
- has thread storage duration. Its lifetime is the entire execution of the thread for which it
- is created, and its stored value is initialized when the thread is started. There is a distinct
- object per thread, and use of the declared name in an expression refers to the object
- associated with the thread evaluating the expression. The result of attempting to
- indirectly access an object with thread storage duration from a thread other than the one
- with which the object is associated is implementation-defined.
-<p><!--para 5 -->
- An object whose identifier is declared with no linkage and without the storage-class
- specifier static has automatic storage duration, as do some compound literals. The
- result of attempting to indirectly access an object with automatic storage duration from a
- thread other than the one with which the object is associated is implementation-defined.
-<p><!--para 6 -->
- For such an object that does not have a variable length array type, its lifetime extends
- from entry into the block with which it is associated until execution of that block ends in
- any way. (Entering an enclosed block or calling a function suspends, but does not end,
- execution of the current block.) If the block is entered recursively, a new instance of the
- object is created each time. The initial value of the object is indeterminate. If an
- initialization is specified for the object, it is performed each time the declaration or
- compound literal is reached in the execution of the block; otherwise, the value becomes
- indeterminate each time the declaration is reached.
-<!--page 57 -->
-<p><!--para 7 -->
- For such an object that does have a variable length array type, its lifetime extends from
- the declaration of the object until execution of the program leaves the scope of the
- declaration.<sup><a href="#note35"><b>35)</b></a></sup> If the scope is entered recursively, a new instance of the object is created
- each time. The initial value of the object is indeterminate.
-<p><!--para 8 -->
- A non-lvalue expression with structure or union type, where the structure or union
- contains a member with array type (including, recursively, members of all contained
- structures and unions) refers to an object with automatic storage duration and temporary
- lifetime.<sup><a href="#note36"><b>36)</b></a></sup> Its lifetime begins when the expression is evaluated and its initial value is the
- value of the expression. Its lifetime ends when the evaluation of the containing full
- expression or full declarator ends. Any attempt to modify an object with temporary
- lifetime results in undefined behavior.
-<p><b> Forward references</b>: array declarators (<a href="#6.7.6.2">6.7.6.2</a>), compound literals (<a href="#6.5.2.5">6.5.2.5</a>), declarators
- (<a href="#6.7.6">6.7.6</a>), function calls (<a href="#6.5.2.2">6.5.2.2</a>), initialization (<a href="#6.7.9">6.7.9</a>), statements (<a href="#6.8">6.8</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note33" href="#note33">33)</a> The term ''constant address'' means that two pointers to the object constructed at possibly different
- times will compare equal. The address may be different during two different executions of the same
- program.
-</small>
-<p><small><a name="note34" href="#note34">34)</a> In the case of a volatile object, the last store need not be explicit in the program.
-</small>
-<p><small><a name="note35" href="#note35">35)</a> Leaving the innermost block containing the declaration, or jumping to a point in that block or an
- embedded block prior to the declaration, leaves the scope of the declaration.
-</small>
-<p><small><a name="note36" href="#note36">36)</a> The address of such an object is taken implicitly when an array member is accessed.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.2.5" href="#6.2.5">6.2.5 Types</a></h4>
-<p><!--para 1 -->
- The meaning of a value stored in an object or returned by a function is determined by the
- type of the expression used to access it. (An identifier declared to be an object is the
- simplest such expression; the type is specified in the declaration of the identifier.) Types
- are partitioned into object types (types that describe objects) and function types (types
- that describe functions). At various points within a translation unit an object type may be
- incomplete (lacking sufficient information to determine the size of objects of that type) or
- complete (having sufficient information).<sup><a href="#note37"><b>37)</b></a></sup>
-<p><!--para 2 -->
- An object declared as type _Bool is large enough to store the values 0 and 1.
-<p><!--para 3 -->
- An object declared as type char is large enough to store any member of the basic
- execution character set. If a member of the basic execution character set is stored in a
- char object, its value is guaranteed to be nonnegative. If any other character is stored in
- a char object, the resulting value is implementation-defined but shall be within the range
- of values that can be represented in that type.
-<p><!--para 4 -->
- There are five standard signed integer types, designated as signed char, short
- int, int, long int, and long long int. (These and other types may be
- designated in several additional ways, as described in <a href="#6.7.2">6.7.2</a>.) There may also be
- implementation-defined extended signed integer types.<sup><a href="#note38"><b>38)</b></a></sup> The standard and extended
- signed integer types are collectively called signed integer types.<sup><a href="#note39"><b>39)</b></a></sup>
-<!--page 58 -->
-<p><!--para 5 -->
- An object declared as type signed char occupies the same amount of storage as a
- ''plain'' char object. A ''plain'' int object has the natural size suggested by the
- architecture of the execution environment (large enough to contain any value in the range
- INT_MIN to INT_MAX as defined in the header <a href="#7.10">&lt;limits.h&gt;</a>).
-<p><!--para 6 -->
- For each of the signed integer types, there is a corresponding (but different) unsigned
- integer type (designated with the keyword unsigned) that uses the same amount of
- storage (including sign information) and has the same alignment requirements. The type
- _Bool and the unsigned integer types that correspond to the standard signed integer
- types are the standard unsigned integer types. The unsigned integer types that
- correspond to the extended signed integer types are the extended unsigned integer types.
- The standard and extended unsigned integer types are collectively called unsigned integer
- types.<sup><a href="#note40"><b>40)</b></a></sup>
-<p><!--para 7 -->
- The standard signed integer types and standard unsigned integer types are collectively
- called the standard integer types, the extended signed integer types and extended
- unsigned integer types are collectively called the extended integer types.
-<p><!--para 8 -->
- For any two integer types with the same signedness and different integer conversion rank
- (see <a href="#6.3.1.1">6.3.1.1</a>), the range of values of the type with smaller integer conversion rank is a
- subrange of the values of the other type.
-<p><!--para 9 -->
- The range of nonnegative values of a signed integer type is a subrange of the
- corresponding unsigned integer type, and the representation of the same value in each
- type is the same.<sup><a href="#note41"><b>41)</b></a></sup> A computation involving unsigned operands can never overflow,
- because a result that cannot be represented by the resulting unsigned integer type is
- reduced modulo the number that is one greater than the largest value that can be
- represented by the resulting type.
-<p><!--para 10 -->
- There are three real floating types, designated as float, double, and long
- double.<sup><a href="#note42"><b>42)</b></a></sup> The set of values of the type float is a subset of the set of values of the
- type double; the set of values of the type double is a subset of the set of values of the
- type long double.
-<!--page 59 -->
-<p><!--para 11 -->
- There are three complex types, designated as float _Complex, double
- _Complex, and long double _Complex.<sup><a href="#note43"><b>43)</b></a></sup> (Complex types are a conditional
- feature that implementations need not support; see <a href="#6.10.8.3">6.10.8.3</a>.) The real floating and
- complex types are collectively called the floating types.
-<p><!--para 12 -->
- For each floating type there is a corresponding real type, which is always a real floating
- type. For real floating types, it is the same type. For complex types, it is the type given
- by deleting the keyword _Complex from the type name.
-<p><!--para 13 -->
- Each complex type has the same representation and alignment requirements as an array
- type containing exactly two elements of the corresponding real type; the first element is
- equal to the real part, and the second element to the imaginary part, of the complex
- number.
-<p><!--para 14 -->
- The type char, the signed and unsigned integer types, and the floating types are
- collectively called the basic types. The basic types are complete object types. Even if the
- implementation defines two or more basic types to have the same representation, they are
- nevertheless different types.<sup><a href="#note44"><b>44)</b></a></sup>
-<p><!--para 15 -->
- The three types char, signed char, and unsigned char are collectively called
- the character types. The implementation shall define char to have the same range,
- representation, and behavior as either signed char or unsigned char.<sup><a href="#note45"><b>45)</b></a></sup>
-<p><!--para 16 -->
- An enumeration comprises a set of named integer constant values. Each distinct
- enumeration constitutes a different enumerated type.
-<p><!--para 17 -->
- The type char, the signed and unsigned integer types, and the enumerated types are
- collectively called integer types. The integer and real floating types are collectively called
- real types.
-<p><!--para 18 -->
- Integer and floating types are collectively called arithmetic types. Each arithmetic type
- belongs to one type domain: the real type domain comprises the real types, the complex
- type domain comprises the complex types.
-<p><!--para 19 -->
- The void type comprises an empty set of values; it is an incomplete object type that
- cannot be completed.
-<!--page 60 -->
-<p><!--para 20 -->
- Any number of derived types can be constructed from the object and function types, as
- follows:
-<ul>
-<li>  An array type describes a contiguously allocated nonempty set of objects with a
- particular member object type, called the element type. The element type shall be
- complete whenever the array type is specified. Array types are characterized by their
- element type and by the number of elements in the array. An array type is said to be
- derived from its element type, and if its element type is T , the array type is sometimes
- called ''array of T ''. The construction of an array type from an element type is called
- ''array type derivation''.
-<li>  A structure type describes a sequentially allocated nonempty set of member objects
- (and, in certain circumstances, an incomplete array), each of which has an optionally
- specified name and possibly distinct type.
-<li>  A union type describes an overlapping nonempty set of member objects, each of
- which has an optionally specified name and possibly distinct type.
-<li>  A function type describes a function with specified return type. A function type is
- characterized by its return type and the number and types of its parameters. A
- function type is said to be derived from its return type, and if its return type is T , the
- function type is sometimes called ''function returning T ''. The construction of a
- function type from a return type is called ''function type derivation''.
-<li>  A pointer type may be derived from a function type or an object type, called the
- referenced type. A pointer type describes an object whose value provides a reference
- to an entity of the referenced type. A pointer type derived from the referenced type T
- is sometimes called ''pointer to T ''. The construction of a pointer type from a
- referenced type is called ''pointer type derivation''. A pointer type is a complete
- object type.
-<li>  An atomic type describes the type designated by the construct _Atomic ( type-
- name ). (Atomic types are a conditional feature that implementations need not
- support; see <a href="#6.10.8.3">6.10.8.3</a>.)
-</ul>
- These methods of constructing derived types can be applied recursively.
-<p><!--para 21 -->
- Arithmetic types and pointer types are collectively called scalar types. Array and
- structure types are collectively called aggregate types.<sup><a href="#note46"><b>46)</b></a></sup>
-<p><!--para 22 -->
- An array type of unknown size is an incomplete type. It is completed, for an identifier of
- that type, by specifying the size in a later declaration (with internal or external linkage).
- A structure or union type of unknown content (as described in <a href="#6.7.2.3">6.7.2.3</a>) is an incomplete
-<!--page 61 -->
- type. It is completed, for all declarations of that type, by declaring the same structure or
- union tag with its defining content later in the same scope.
-<p><!--para 23 -->
- A type has known constant size if the type is not incomplete and is not a variable length
- array type.
-<p><!--para 24 -->
- Array, function, and pointer types are collectively called derived declarator types. A
- declarator type derivation from a type T is the construction of a derived declarator type
- from T by the application of an array-type, a function-type, or a pointer-type derivation to
- T.
-<p><!--para 25 -->
- A type is characterized by its type category, which is either the outermost derivation of a
- derived type (as noted above in the construction of derived types), or the type itself if the
- type consists of no derived types.
-<p><!--para 26 -->
- Any type so far mentioned is an unqualified type. Each unqualified type has several
- qualified versions of its type,<sup><a href="#note47"><b>47)</b></a></sup> corresponding to the combinations of one, two, or all
- three of the const, volatile, and restrict qualifiers. The qualified or unqualified
- versions of a type are distinct types that belong to the same type category and have the
- same representation and alignment requirements.<sup><a href="#note48"><b>48)</b></a></sup> A derived type is not qualified by the
- qualifiers (if any) of the type from which it is derived.
-<p><!--para 27 -->
- Further, there is the _Atomic qualifier. The presence of the _Atomic qualifier
- designates an atomic type. The size, representation, and alignment of an atomic type
- need not be the same as those of the corresponding unqualified type. Therefore, this
- Standard explicitly uses the phrase ''atomic, qualified or unqualified type'' whenever the
- atomic version of a type is permitted along with the other qualified versions of a type.
- The phrase ''qualified or unqualified type'', without specific mention of atomic, does not
- include the atomic types.
-<p><!--para 28 -->
- A pointer to void shall have the same representation and alignment requirements as a
- pointer to a character type.<sup><a href="#note48"><b>48)</b></a></sup> Similarly, pointers to qualified or unqualified versions of
- compatible types shall have the same representation and alignment requirements. All
- pointers to structure types shall have the same representation and alignment requirements
- as each other. All pointers to union types shall have the same representation and
- alignment requirements as each other. Pointers to other types need not have the same
- representation or alignment requirements.
-<p><!--para 29 -->
- EXAMPLE 1 The type designated as ''float *'' has type ''pointer to float''. Its type category is
- pointer, not a floating type. The const-qualified version of this type is designated as ''float * const''
- whereas the type designated as ''const float *'' is not a qualified type -- its type is ''pointer to const-
-<!--page 62 -->
- qualified float'' and is a pointer to a qualified type.
-<p><!--para 30 -->
- EXAMPLE 2 The type designated as ''struct tag (*[5])(float)'' has type ''array of pointer to
- function returning struct tag''. The array has length five and the function has a single parameter of type
- float. Its type category is array.
-<p><b> Forward references</b>: compatible type and composite type (<a href="#6.2.7">6.2.7</a>), declarations (<a href="#6.7">6.7</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note37" href="#note37">37)</a> A type may be incomplete or complete throughout an entire translation unit, or it may change states at
- different points within a translation unit.
-</small>
-<p><small><a name="note38" href="#note38">38)</a> Implementation-defined keywords shall have the form of an identifier reserved for any use as
- described in <a href="#7.1.3">7.1.3</a>.
-</small>
-<p><small><a name="note39" href="#note39">39)</a> Therefore, any statement in this Standard about signed integer types also applies to the extended
- signed integer types.
-</small>
-<p><small><a name="note40" href="#note40">40)</a> Therefore, any statement in this Standard about unsigned integer types also applies to the extended
- unsigned integer types.
-</small>
-<p><small><a name="note41" href="#note41">41)</a> The same representation and alignment requirements are meant to imply interchangeability as
- arguments to functions, return values from functions, and members of unions.
-</small>
-<p><small><a name="note42" href="#note42">42)</a> See ''future language directions'' (<a href="#6.11.1">6.11.1</a>).
-</small>
-<p><small><a name="note43" href="#note43">43)</a> A specification for imaginary types is in <a href="#G">annex G</a>.
-</small>
-<p><small><a name="note44" href="#note44">44)</a> An implementation may define new keywords that provide alternative ways to designate a basic (or
- any other) type; this does not violate the requirement that all basic types be different.
- Implementation-defined keywords shall have the form of an identifier reserved for any use as
- described in <a href="#7.1.3">7.1.3</a>.
-</small>
-<p><small><a name="note45" href="#note45">45)</a> CHAR_MIN, defined in <a href="#7.10">&lt;limits.h&gt;</a>, will have one of the values 0 or SCHAR_MIN, and this can be
- used to distinguish the two options. Irrespective of the choice made, char is a separate type from the
- other two and is not compatible with either.
-</small>
-<p><small><a name="note46" href="#note46">46)</a> Note that aggregate type does not include union type because an object with union type can only
- contain one member at a time.
-</small>
-<p><small><a name="note47" href="#note47">47)</a> See <a href="#6.7.3">6.7.3</a> regarding qualified array and function types.
-</small>
-<p><small><a name="note48" href="#note48">48)</a> The same representation and alignment requirements are meant to imply interchangeability as
- arguments to functions, return values from functions, and members of unions.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.2.6" href="#6.2.6">6.2.6 Representations of types</a></h4>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.2.6.1" href="#6.2.6.1">6.2.6.1 General</a></h5>
-<p><!--para 1 -->
- The representations of all types are unspecified except as stated in this subclause.
-<p><!--para 2 -->
- 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.
-<p><!--para 3 -->
- Values stored in unsigned bit-fields and objects of type unsigned char shall be
- represented using a pure binary notation.<sup><a href="#note49"><b>49)</b></a></sup>
-<p><!--para 4 -->
- Values stored in non-bit-field objects of any other object type consist of n x CHAR_BIT
- bits, where n is the size of an object of that type, in bytes. The value may be copied into
- an object of type unsigned char [n] (e.g., by memcpy); the resulting set of bytes is
- called the object representation of the value. Values stored in bit-fields consist of m bits,
- where m is the size specified for the bit-field. The object representation is the set of m
- bits the bit-field comprises in the addressable storage unit holding it. Two values (other
- than NaNs) with the same object representation compare equal, but values that compare
- equal may have different object representations.
-<p><!--para 5 -->
- Certain object representations need not represent a value of the object type. If the stored
- value of an object has such a representation and is read by an lvalue expression that does
- not have character type, the behavior is undefined. If such a representation is produced
- by a side effect that modifies all or any part of the object by an lvalue expression that
- does not have character type, the behavior is undefined.<sup><a href="#note50"><b>50)</b></a></sup> Such a representation is called
- a trap representation.
-<p><!--para 6 -->
- When a value is stored in an object of structure or union type, including in a member
- object, the bytes of the object representation that correspond to any padding bytes take
- unspecified values.<sup><a href="#note51"><b>51)</b></a></sup> The value of a structure or union object is never a trap
-<!--page 63 -->
- representation, even though the value of a member of the structure or union object may be
- a trap representation.
-<p><!--para 7 -->
- When a value is stored in a member of an object of union type, the bytes of the object
- representation that do not correspond to that member but do correspond to other members
- take unspecified values.
-<p><!--para 8 -->
- Where an operator is applied to a value that has more than one object representation,
- which object representation is used shall not affect the value of the result.<sup><a href="#note52"><b>52)</b></a></sup> Where a
- value is stored in an object using a type that has more than one object representation for
- that value, it is unspecified which representation is used, but a trap representation shall
- not be generated.
-<p><!--para 9 -->
- Loads and stores of objects with                            atomic       types     are     done      with
- memory_order_seq_cst semantics.
-<p><b> Forward references</b>: declarations (<a href="#6.7">6.7</a>), expressions (<a href="#6.5">6.5</a>), lvalues, arrays, and function
- designators (<a href="#6.3.2.1">6.3.2.1</a>), order and consistency (<a href="#7.17.3">7.17.3</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note49" href="#note49">49)</a> A positional representation for integers that uses the binary digits 0 and 1, in which the values
- represented by successive bits are additive, begin with 1, and are multiplied by successive integral
- powers of 2, except perhaps the bit with the highest position. (Adapted from the American National
- Dictionary for Information Processing Systems.) A byte contains CHAR_BIT bits, and the values of
- type unsigned char range from 0 to 2
-
-<pre>
-                                           CHAR_BIT
-                                                     - 1.
-</pre>
-</small>
-<p><small><a name="note50" href="#note50">50)</a> Thus, an automatic variable can be initialized to a trap representation without causing undefined
- behavior, but the value of the variable cannot be used until a proper value is stored in it.
-</small>
-<p><small><a name="note51" href="#note51">51)</a> Thus, for example, structure assignment need not copy any padding bits.
-</small>
-<p><small><a name="note52" href="#note52">52)</a> It is possible for objects x and y with the same effective type T to have the same value when they are
- accessed as objects of type T, but to have different values in other contexts. In particular, if == is
- defined for type T, then x == y does not imply that memcmp(&amp;x, &amp;y, sizeof (T)) == 0.
- Furthermore, x == y does not necessarily imply that x and y have the same value; other operations
- on values of type T may distinguish between them.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.2.6.2" href="#6.2.6.2">6.2.6.2 Integer types</a></h5>
-<p><!--para 1 -->
- For unsigned integer types other than unsigned char, the bits of the object
- representation shall be divided into two groups: value bits and padding bits (there need
- not be any of the latter). If there are N value bits, each bit shall represent a different
- power of 2 between 1 and 2 N -1 , so that objects of that type shall be capable of
- representing values from 0 to 2 N - 1 using a pure binary representation; this shall be
- known as the value representation. The values of any padding bits are unspecified.<sup><a href="#note53"><b>53)</b></a></sup>
-<p><!--para 2 -->
- For signed integer types, the bits of the object representation shall be divided into three
- groups: value bits, padding bits, and the sign bit. There need not be any padding bits;
- signed char shall not have any padding bits. There shall be exactly one sign bit.
- Each bit that is a value bit shall have the same value as the same bit in the object
- representation of the corresponding unsigned type (if there are M value bits in the signed
- type and N in the unsigned type, then M &lt;= N ). If the sign bit is zero, it shall not affect
-<!--page 64 -->
- the resulting value. If the sign bit is one, the value shall be modified in one of the
- following ways:
-<ul>
-<li>  the corresponding value with sign bit 0 is negated (sign and magnitude);
-<li>  the sign bit has the value -(2 M ) (two's complement);
-<li>  the sign bit has the value -(2 M - 1) (ones' complement).
-</ul>
- Which of these applies is implementation-defined, as is whether the value with sign bit 1
- and all value bits zero (for the first two), or with sign bit and all value bits 1 (for ones'
- complement), is a trap representation or a normal value. In the case of sign and
- magnitude and ones' complement, if this representation is a normal value it is called a
- negative zero.
-<p><!--para 3 -->
- If the implementation supports negative zeros, they shall be generated only by:
-<ul>
-<li>  the &amp;, |, ^, ~, &lt;&lt;, and &gt;&gt; operators with operands that produce such a value;
-<li>  the +, -, *, /, and % operators where one operand is a negative zero and the result is
- zero;
-<li>  compound assignment operators based on the above cases.
-</ul>
- It is unspecified whether these cases actually generate a negative zero or a normal zero,
- and whether a negative zero becomes a normal zero when stored in an object.
-<p><!--para 4 -->
- If the implementation does not support negative zeros, the behavior of the &amp;, |, ^, ~, &lt;&lt;,
- and &gt;&gt; operators with operands that would produce such a value is undefined.
-<p><!--para 5 -->
- The values of any padding bits are unspecified.<sup><a href="#note54"><b>54)</b></a></sup> A valid (non-trap) object representation
- of a signed integer type where the sign bit is zero is a valid object representation of the
- corresponding unsigned type, and shall represent the same value. For any integer type,
- the object representation where all the bits are zero shall be a representation of the value
- zero in that type.
-<p><!--para 6 -->
- The precision of an integer type is the number of bits it uses to represent values,
- excluding any sign and padding bits. The width of an integer type is the same but
- including any sign bit; thus for unsigned integer types the two values are the same, while
- for signed integer types the width is one greater than the precision.
-<!--page 65 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note53" href="#note53">53)</a> Some combinations of padding bits might generate trap representations, for example, if one padding
- bit is a parity bit. Regardless, no arithmetic operation on valid values can generate a trap
- representation other than as part of an exceptional condition such as an overflow, and this cannot occur
- with unsigned types. All other combinations of padding bits are alternative object representations of
- the value specified by the value bits.
-</small>
-<p><small><a name="note54" href="#note54">54)</a> Some combinations of padding bits might generate trap representations, for example, if one padding
- bit is a parity bit. Regardless, no arithmetic operation on valid values can generate a trap
- representation other than as part of an exceptional condition such as an overflow. All other
- combinations of padding bits are alternative object representations of the value specified by the value
- bits.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.2.7" href="#6.2.7">6.2.7 Compatible type and composite type</a></h4>
-<p><!--para 1 -->
- Two types have compatible type if their types are the same. Additional rules for
- determining whether two types are compatible are described in <a href="#6.7.2">6.7.2</a> for type specifiers,
- in <a href="#6.7.3">6.7.3</a> for type qualifiers, and in <a href="#6.7.6">6.7.6</a> for declarators.<sup><a href="#note55"><b>55)</b></a></sup> Moreover, two structure,
- union, or enumerated types declared in separate translation units are compatible if their
- tags and members satisfy the following requirements: If one is declared with a tag, the
- other shall be declared with the same tag. If both are completed anywhere within their
- respective translation units, then the following additional requirements apply: there shall
- be a one-to-one correspondence between their members such that each pair of
- corresponding members are declared with compatible types; if one member of the pair is
- declared with an alignment specifier, the other is declared with an equivalent alignment
- specifier; and if one member of the pair is declared with a name, the other is declared
- with the same name. For two structures, corresponding members shall be declared in the
- same order. For two structures or unions, corresponding bit-fields shall have the same
- widths. For two enumerations, corresponding members shall have the same values.
-<p><!--para 2 -->
- All declarations that refer to the same object or function shall have compatible type;
- otherwise, the behavior is undefined.
-<p><!--para 3 -->
- A composite type can be constructed from two types that are compatible; it is a type that
- is compatible with both of the two types and satisfies the following conditions:
-<ul>
-<li>  If both types are array types, the following rules are applied:
-<ul>
-<li> If one type is an array of known constant size, the composite type is an array of
- that size.
-<li> Otherwise, if one type is a variable length array whose size is specified by an
- expression that is not evaluated, the behavior is undefined.
-<li> Otherwise, if one type is a variable length array whose size is specified, the
- composite type is a variable length array of that size.
-<li> Otherwise, if one type is a variable length array of unspecified size, the composite
- type is a variable length array of unspecified size.
-<li> Otherwise, both types are arrays of unknown size and the composite type is an
- array of unknown size.
-</ul>
-   The element type of the composite type is the composite type of the two element
-   types.
-<li>  If only one type is a function type with a parameter type list (a function prototype),
- the composite type is a function prototype with the parameter type list.
-<!--page 66 -->
-<li>  If both types are function types with parameter type lists, the type of each parameter
- in the composite parameter type list is the composite type of the corresponding
- parameters.
-</ul>
- These rules apply recursively to the types from which the two types are derived.
-<p><!--para 4 -->
- For an identifier with internal or external linkage declared in a scope in which a prior
- declaration of that identifier is visible,<sup><a href="#note56"><b>56)</b></a></sup> if the prior declaration specifies internal or
- external linkage, the type of the identifier at the later declaration becomes the composite
- type.
-<p><b> Forward references</b>: array declarators (<a href="#6.7.6.2">6.7.6.2</a>).
-<p><!--para 5 -->
- EXAMPLE        Given the following two file scope declarations:
-<pre>
-          int f(int (*)(), double (*)[3]);
-          int f(int (*)(char *), double (*)[]);
-</pre>
- The resulting composite type for the function is:
-<pre>
-          int f(int (*)(char *), double (*)[3]);
-</pre>
-
-<p><b>Footnotes</b>
-<p><small><a name="note55" href="#note55">55)</a> Two types need not be identical to be compatible.
-</small>
-<p><small><a name="note56" href="#note56">56)</a> As specified in <a href="#6.2.1">6.2.1</a>, the later declaration might hide the prior declaration.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.2.8" href="#6.2.8">6.2.8 Alignment of objects</a></h4>
-<p><!--para 1 -->
- Complete object types have alignment requirements which place restrictions on the
- addresses at which objects of that type may be allocated. An alignment is an
- implementation-defined integer value representing the number of bytes between
- successive addresses at which a given object can be allocated. An object type imposes an
- alignment requirement on every object of that type: stricter alignment can be requested
- using the _Alignas keyword.
-<p><!--para 2 -->
- A fundamental alignment is represented by an alignment less than or equal to the greatest
- alignment supported by the implementation in all contexts, which is equal to
- alignof(max_align_t).
-<p><!--para 3 -->
- An extended alignment is represented by an alignment greater than
- alignof(max_align_t). It is implementation-defined whether any extended
- alignments are supported and the contexts in which they are supported. A type having an
- extended alignment requirement is an over-aligned type.<sup><a href="#note57"><b>57)</b></a></sup>
-<p><!--para 4 -->
- Alignments are represented as values of the type size_t. Valid alignments include only
- those values returned by an alignof expression for fundamental types, plus an
- additional implementation-defined set of values, which may be empty. Every valid
- alignment value shall be a nonnegative integral power of two.
-<!--page 67 -->
-<p><!--para 5 -->
- Alignments have an order from weaker to stronger or stricter alignments. Stricter
- alignments have larger alignment values. An address that satisfies an alignment
- requirement also satisfies any weaker valid alignment requirement.
-<p><!--para 6 -->
- The alignment requirement of a complete type can be queried using an alignof
- expression. The types char, signed char, and unsigned char shall have the
- weakest alignment requirement.
-<p><!--para 7 -->
- Comparing alignments is meaningful and provides the obvious results:
-<ul>
-<li>  Two alignments are equal when their numeric values are equal.
-<li>  Two alignments are different when their numeric values are not equal.
-<li>  When an alignment is larger than another it represents a stricter alignment.
-<!--page 68 -->
-</ul>
-
-<p><b>Footnotes</b>
-<p><small><a name="note57" href="#note57">57)</a> Every over-aligned type is, or contains, a structure or union type with a member to which an extended
- alignment has been applied.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="6.3" href="#6.3">6.3 Conversions</a></h3>
-<p><!--para 1 -->
- Several operators convert operand values from one type to another automatically. This
- subclause specifies the result required from such an implicit conversion, as well as those
- that result from a cast operation (an explicit conversion). The list in <a href="#6.3.1.8">6.3.1.8</a> summarizes
- the conversions performed by most ordinary operators; it is supplemented as required by
- the discussion of each operator in <a href="#6.5">6.5</a>.
-<p><!--para 2 -->
- Conversion of an operand value to a compatible type causes no change to the value or the
- representation.
-<p><b> Forward references</b>: cast operators (<a href="#6.5.4">6.5.4</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.3.1" href="#6.3.1">6.3.1 Arithmetic operands</a></h4>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.1.1" href="#6.3.1.1">6.3.1.1 Boolean, characters, and integers</a></h5>
-<p><!--para 1 -->
- Every integer type has an integer conversion rank defined as follows:
-<ul>
-<li>  No two signed integer types shall have the same rank, even if they have the same
- representation.
-<li>  The rank of a signed integer type shall be greater than the rank of any signed integer
- type with less precision.
-<li>  The rank of long long int shall be greater than the rank of long int, which
- shall be greater than the rank of int, which shall be greater than the rank of short
- int, which shall be greater than the rank of signed char.
-<li>  The rank of any unsigned integer type shall equal the rank of the corresponding
- signed integer type, if any.
-<li>  The rank of any standard integer type shall be greater than the rank of any extended
- integer type with the same width.
-<li>  The rank of char shall equal the rank of signed char and unsigned char.
-<li>  The rank of _Bool shall be less than the rank of all other standard integer types.
-<li>  The rank of any enumerated type shall equal the rank of the compatible integer type
- (see <a href="#6.7.2.2">6.7.2.2</a>).
-<li>  The rank of any extended signed integer type relative to another extended signed
- integer type with the same precision is implementation-defined, but still subject to the
- other rules for determining the integer conversion rank.
-<li>  For all integer types T1, T2, and T3, if T1 has greater rank than T2 and T2 has
- greater rank than T3, then T1 has greater rank than T3.
-</ul>
-<p><!--para 2 -->
- The following may be used in an expression wherever an int or unsigned int may
- be used:
-<!--page 69 -->
-<ul>
-<li>  An object or expression with an integer type (other than int or unsigned int)
- whose integer conversion rank is less than or equal to the rank of int and
- unsigned int.
-<li>  A bit-field of type _Bool, int, signed int, or unsigned int.
-</ul>
- If an int can represent all values of the original type (as restricted by the width, for a
- bit-field), the value is converted to an int; otherwise, it is converted to an unsigned
- int. These are called the integer promotions.<sup><a href="#note58"><b>58)</b></a></sup> All other types are unchanged by the
- integer promotions.
-<p><!--para 3 -->
- The integer promotions preserve value including sign. As discussed earlier, whether a
- ''plain'' char is treated as signed is implementation-defined.
-<p><b> Forward references</b>: enumeration specifiers (<a href="#6.7.2.2">6.7.2.2</a>), structure and union specifiers
- (<a href="#6.7.2.1">6.7.2.1</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note58" href="#note58">58)</a> The integer promotions are applied only: as part of the usual arithmetic conversions, to certain
- argument expressions, to the operands of the unary +, -, and ~ operators, and to both operands of the
- shift operators, as specified by their respective subclauses.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.1.2" href="#6.3.1.2">6.3.1.2 Boolean type</a></h5>
-<p><!--para 1 -->
- When any scalar value is converted to _Bool, the result is 0 if the value compares equal
- to 0; otherwise, the result is 1.<sup><a href="#note59"><b>59)</b></a></sup>
-
-<p><b>Footnotes</b>
-<p><small><a name="note59" href="#note59">59)</a> NaNs do not compare equal to 0 and thus convert to 1.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.1.3" href="#6.3.1.3">6.3.1.3 Signed and unsigned integers</a></h5>
-<p><!--para 1 -->
- When a value with integer type is converted to another integer type other than _Bool, if
- the value can be represented by the new type, it is unchanged.
-<p><!--para 2 -->
- Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or
- subtracting one more than the maximum value that can be represented in the new type
- until the value is in the range of the new type.<sup><a href="#note60"><b>60)</b></a></sup>
-<p><!--para 3 -->
- Otherwise, the new type is signed and the value cannot be represented in it; either the
- result is implementation-defined or an implementation-defined signal is raised.
-
-<p><b>Footnotes</b>
-<p><small><a name="note60" href="#note60">60)</a> The rules describe arithmetic on the mathematical value, not the value of a given type of expression.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.1.4" href="#6.3.1.4">6.3.1.4 Real floating and integer</a></h5>
-<p><!--para 1 -->
- When a finite value of real floating type is converted to an integer type other than _Bool,
- the fractional part is discarded (i.e., the value is truncated toward zero). If the value of
- the integral part cannot be represented by the integer type, the behavior is undefined.<sup><a href="#note61"><b>61)</b></a></sup>
-<!--page 70 -->
-<p><!--para 2 -->
- When a value of integer type is converted to a real floating type, if the value being
- converted can be represented exactly in the new type, it is unchanged. If the value being
- converted is in the range of values that can be represented but cannot be represented
- exactly, the result is either the nearest higher or nearest lower representable value, chosen
- in an implementation-defined manner. If the value being converted is outside the range of
- values that can be represented, the behavior is undefined. Results of some implicit
- conversions (<a href="#6.3.1.8">6.3.1.8</a>, <a href="#6.8.6.4">6.8.6.4</a>) may be represented in greater precision and range than that
- required by the new type.
-
-<p><b>Footnotes</b>
-<p><small><a name="note61" href="#note61">61)</a> The remaindering operation performed when a value of integer type is converted to unsigned type
- need not be performed when a value of real floating type is converted to unsigned type. Thus, the
- range of portable real floating values is (-1, Utype_MAX+1).
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.1.5" href="#6.3.1.5">6.3.1.5 Real floating types</a></h5>
-<p><!--para 1 -->
- When a value of real floating type is converted to a real floating type, if the value being
- converted can be represented exactly in the new type, it is unchanged. If the value being
- converted is in the range of values that can be represented but cannot be represented
- exactly, the result is either the nearest higher or nearest lower representable value, chosen
- in an implementation-defined manner. If the value being converted is outside the range of
- values that can be represented, the behavior is undefined. Results of some implicit
- conversions (<a href="#6.3.1.8">6.3.1.8</a>, <a href="#6.8.6.4">6.8.6.4</a>) may be represented in greater precision and range than that
- required by the new type.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.1.6" href="#6.3.1.6">6.3.1.6 Complex types</a></h5>
-<p><!--para 1 -->
- When a value of complex type is converted to another complex type, both the real and
- imaginary parts follow the conversion rules for the corresponding real types.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.1.7" href="#6.3.1.7">6.3.1.7 Real and complex</a></h5>
-<p><!--para 1 -->
- When a value of real type is converted to a complex type, the real part of the complex
- result value is determined by the rules of conversion to the corresponding real type and
- the imaginary part of the complex result value is a positive zero or an unsigned zero.
-<p><!--para 2 -->
- When a value of complex type is converted to a real type, the imaginary part of the
- complex value is discarded and the value of the real part is converted according to the
- conversion rules for the corresponding real type.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.1.8" href="#6.3.1.8">6.3.1.8 Usual arithmetic conversions</a></h5>
-<p><!--para 1 -->
- Many operators that expect operands of arithmetic type cause conversions and yield result
- types in a similar way. The purpose is to determine a common real type for the operands
- and result. For the specified operands, each operand is converted, without change of type
- domain, to a type whose corresponding real type is the common real type. Unless
- explicitly stated otherwise, the common real type is also the corresponding real type of
- the result, whose type domain is the type domain of the operands if they are the same,
- and complex otherwise. This pattern is called the usual arithmetic conversions:
-<!--page 71 -->
-<pre>
-       First, if the corresponding real type of either operand is long double, the other
-       operand is converted, without change of type domain, to a type whose
-        corresponding real type is long double.
-        Otherwise, if the corresponding real type of either operand is double, the other
-        operand is converted, without change of type domain, to a type whose
-        corresponding real type is double.
-        Otherwise, if the corresponding real type of either operand is float, the other
-        operand is converted, without change of type domain, to a type whose
-        corresponding real type is float.<sup><a href="#note62"><b>62)</b></a></sup>
-        Otherwise, the integer promotions are performed on both operands. Then the
-        following rules are applied to the promoted operands:
-               If both operands have the same type, then no further conversion is needed.
-               Otherwise, if both operands have signed integer types or both have unsigned
-               integer types, the operand with the type of lesser integer conversion rank is
-               converted to the type of the operand with greater rank.
-               Otherwise, if the operand that has unsigned integer type has rank greater or
-               equal to the rank of the type of the other operand, then the operand with
-               signed integer type is converted to the type of the operand with unsigned
-               integer type.
-               Otherwise, if the type of the operand with signed integer type can represent
-               all of the values of the type of the operand with unsigned integer type, then
-               the operand with unsigned integer type is converted to the type of the
-               operand with signed integer type.
-               Otherwise, both operands are converted to the unsigned integer type
-               corresponding to the type of the operand with signed integer type.
-</pre>
-<p><!--para 2 -->
- The values of floating operands and of the results of floating expressions may be
- represented in greater precision and range than that required by the type; the types are not
- changed thereby.<sup><a href="#note63"><b>63)</b></a></sup>
-<!--page 72 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note62" href="#note62">62)</a> For example, addition of a double _Complex and a float entails just the conversion of the
- float operand to double (and yields a double _Complex result).
-</small>
-<p><small><a name="note63" href="#note63">63)</a> The cast and assignment operators are still required to remove extra range and precision.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.3.2" href="#6.3.2">6.3.2 Other operands</a></h4>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.2.1" href="#6.3.2.1">6.3.2.1 Lvalues, arrays, and function designators</a></h5>
-<p><!--para 1 -->
- An lvalue is an expression (with an object type other than void) that potentially
- designates an object;<sup><a href="#note64"><b>64)</b></a></sup> if an lvalue does not designate an object when it is evaluated, the
- behavior is undefined. When an object is said to have a particular type, the type is
- specified by the lvalue used to designate the object. A modifiable lvalue is an lvalue that
- does not have array type, does not have an incomplete type, does not have a const-
- qualified type, and if it is a structure or union, does not have any member (including,
- recursively, any member or element of all contained aggregates or unions) with a const-
- qualified type.
-<p><!--para 2 -->
- Except when it is the operand of the sizeof operator, the unary &amp; operator, the ++
- operator, the -- operator, or the left operand of the . operator or an assignment operator,
- an lvalue that does not have array type is converted to the value stored in the designated
- object (and is no longer an lvalue); this is called lvalue conversion. If the lvalue has
- qualified type, the value has the unqualified version of the type of the lvalue; additionally,
- if the lvalue has atomic type, the value has the non-atomic version of the type of the
- lvalue; otherwise, the value has the type of the lvalue. If the lvalue has an incomplete
- type and does not have array type, the behavior is undefined. If the lvalue designates an
- object of automatic storage duration that could have been declared with the register
- storage class (never had its address taken), and that object is uninitialized (not declared
- with an initializer and no assignment to it has been performed prior to use), the behavior
- is undefined.
-<p><!--para 3 -->
- Except when it is the operand of the sizeof operator or the unary &amp; operator, or is a
- string literal used to initialize an array, an expression that has type ''array of type'' is
- converted to an expression with type ''pointer to type'' that points to the initial element of
- the array object and is not an lvalue. If the array object has register storage class, the
- behavior is undefined.
-<p><!--para 4 -->
- A function designator is an expression that has function type. Except when it is the
- operand of the sizeof operator<sup><a href="#note65"><b>65)</b></a></sup> or the unary &amp; operator, a function designator with
- type ''function returning type'' is converted to an expression that has type ''pointer to
-<!--page 73 -->
- function returning type''.
-<p><b> Forward references</b>: address and indirection operators (<a href="#6.5.3.2">6.5.3.2</a>), assignment operators
- (<a href="#6.5.16">6.5.16</a>), common definitions <a href="#7.19">&lt;stddef.h&gt;</a> (<a href="#7.19">7.19</a>), initialization (<a href="#6.7.9">6.7.9</a>), postfix
- increment and decrement operators (<a href="#6.5.2.4">6.5.2.4</a>), prefix increment and decrement operators
- (<a href="#6.5.3.1">6.5.3.1</a>), the sizeof operator (<a href="#6.5.3.4">6.5.3.4</a>), structure and union members (<a href="#6.5.2.3">6.5.2.3</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note64" href="#note64">64)</a> The name ''lvalue'' comes originally from the assignment expression E1 = E2, in which the left
- operand E1 is required to be a (modifiable) lvalue. It is perhaps better considered as representing an
- object ''locator value''. What is sometimes called ''rvalue'' is in this International Standard described
- as the ''value of an expression''.
-  An obvious example of an lvalue is an identifier of an object. As a further example, if E is a unary
-  expression that is a pointer to an object, *E is an lvalue that designates the object to which E points.
-</small>
-<p><small><a name="note65" href="#note65">65)</a> Because this conversion does not occur, the operand of the sizeof operator remains a function
- designator and violates the constraint in <a href="#6.5.3.4">6.5.3.4</a>.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.2.2" href="#6.3.2.2">6.3.2.2 void</a></h5>
-<p><!--para 1 -->
- The (nonexistent) value of a void expression (an expression that has type void) shall not
- be used in any way, and implicit or explicit conversions (except to void) shall not be
- applied to such an expression. If an expression of any other type is evaluated as a void
- expression, its value or designator is discarded. (A void expression is evaluated for its
- side effects.)
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.3.2.3" href="#6.3.2.3">6.3.2.3 Pointers</a></h5>
-<p><!--para 1 -->
- A pointer to void may be converted to or from a pointer to any object type. A pointer to
- any object type may be converted to a pointer to void and back again; the result shall
- compare equal to the original pointer.
-<p><!--para 2 -->
- For any qualifier q, a pointer to a non-q-qualified type may be converted to a pointer to
- the q-qualified version of the type; the values stored in the original and converted pointers
- shall compare equal.
-<p><!--para 3 -->
- An integer constant expression with the value 0, or such an expression cast to type
- void *, is called a null pointer constant.<sup><a href="#note66"><b>66)</b></a></sup> If a null pointer constant is converted to a
- pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
- to a pointer to any object or function.
-<p><!--para 4 -->
- Conversion of a null pointer to another pointer type yields a null pointer of that type.
- Any two null pointers shall compare equal.
-<p><!--para 5 -->
- An integer may be converted to any pointer type. Except as previously specified, the
- result is implementation-defined, might not be correctly aligned, might not point to an
- entity of the referenced type, and might be a trap representation.<sup><a href="#note67"><b>67)</b></a></sup>
-<p><!--para 6 -->
- Any pointer type may be converted to an integer type. Except as previously specified, the
- result is implementation-defined. If the result cannot be represented in the integer type,
- the behavior is undefined. The result need not be in the range of values of any integer
- type.
-<!--page 74 -->
-<p><!--para 7 -->
- A pointer to an object type may be converted to a pointer to a different object type. If the
- resulting pointer is not correctly aligned<sup><a href="#note68"><b>68)</b></a></sup> for the referenced type, the behavior is
- undefined. Otherwise, when converted back again, the result shall compare equal to the
- original pointer. When a pointer to an object is converted to a pointer to a character type,
- the result points to the lowest addressed byte of the object. Successive increments of the
- result, up to the size of the object, yield pointers to the remaining bytes of the object.
-<p><!--para 8 -->
- A pointer to a function of one type may be converted to a pointer to a function of another
- type and back again; the result shall compare equal to the original pointer. If a converted
- pointer is used to call a function whose type is not compatible with the referenced type,
- the behavior is undefined.
-<p><b> Forward references</b>: cast operators (<a href="#6.5.4">6.5.4</a>), equality operators (<a href="#6.5.9">6.5.9</a>), integer types
- capable of holding object pointers (<a href="#7.20.1.4">7.20.1.4</a>), simple assignment (<a href="#6.5.16.1">6.5.16.1</a>).
-<!--page 75 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note66" href="#note66">66)</a> The macro NULL is defined in <a href="#7.19">&lt;stddef.h&gt;</a> (and other headers) as a null pointer constant; see <a href="#7.19">7.19</a>.
-</small>
-<p><small><a name="note67" href="#note67">67)</a> The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to
- be consistent with the addressing structure of the execution environment.
-</small>
-<p><small><a name="note68" href="#note68">68)</a> In general, the concept ''correctly aligned'' is transitive: if a pointer to type A is correctly aligned for a
- pointer to type B, which in turn is correctly aligned for a pointer to type C, then a pointer to type A is
- correctly aligned for a pointer to type C.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="6.4" href="#6.4">6.4 Lexical elements</a></h3>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          token:
-                   keyword
-                   identifier
-                   constant
-                   string-literal
-                   punctuator
-          preprocessing-token:
-                 header-name
-                 identifier
-                 pp-number
-                 character-constant
-                 string-literal
-                 punctuator
-                 each non-white-space character that cannot be one of the above
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each preprocessing token that is converted to a token shall have the lexical form of a
- keyword, an identifier, a constant, a string literal, or a punctuator.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- 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, and punctuators.
- A preprocessing token is the minimal lexical element of the language in translation
- phases 3 through 6. The categories of preprocessing tokens are: header names,
- identifiers, preprocessing numbers, character constants, string literals, punctuators, and
- single non-white-space characters that do not lexically match the other preprocessing
- token categories.<sup><a href="#note69"><b>69)</b></a></sup> If a ' or a " character matches the last category, the behavior is
- undefined. Preprocessing tokens can be separated by white space; this consists of
- comments (described later), or white-space characters (space, horizontal tab, new-line,
- vertical tab, and form-feed), or both. As described in <a href="#6.10">6.10</a>, 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.
-<!--page 76 -->
-<p><!--para 4 -->
- 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. There is one exception to this rule: header name preprocessing
- tokens are recognized only within #include preprocessing directives and in
- implementation-defined locations within #pragma directives. In such contexts, a
- sequence of characters that could be either a header name or a string literal is recognized
- as the former.
-<p><!--para 5 -->
- EXAMPLE 1 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.
-<p><!--para 6 -->
- EXAMPLE 2 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.
-<p><b> Forward references</b>: character constants (<a href="#6.4.4.4">6.4.4.4</a>), comments (<a href="#6.4.9">6.4.9</a>), expressions (<a href="#6.5">6.5</a>),
- floating constants (<a href="#6.4.4.2">6.4.4.2</a>), header names (<a href="#6.4.7">6.4.7</a>), macro replacement (<a href="#6.10.3">6.10.3</a>), postfix
- increment and decrement operators (<a href="#6.5.2.4">6.5.2.4</a>), prefix increment and decrement operators
- (<a href="#6.5.3.1">6.5.3.1</a>), preprocessing directives (<a href="#6.10">6.10</a>), preprocessing numbers (<a href="#6.4.8">6.4.8</a>), string literals
- (<a href="#6.4.5">6.4.5</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note69" href="#note69">69)</a> An additional category, placemarkers, is used internally in translation phase 4 (see <a href="#6.10.3.3">6.10.3.3</a>); it cannot
- occur in source files.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.1" href="#6.4.1">6.4.1 Keywords</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          keyword: one of
-                alignof                         goto                         union
-                auto                            if                           unsigned
-                break                           inline                       void
-                case                            int                          volatile
-                char                            long                         while
-                const                           register                     _Alignas
-                continue                        restrict                     _Atomic
-                default                         return                       _Bool
-                do                              short                        _Complex
-                double                          signed                       _Generic
-                else                            sizeof                       _Imaginary
-                enum                            static                       _Noreturn
-                extern                          struct                       _Static_assert
-                float                           switch                       _Thread_local
-                for                             typedef
-</pre>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- The above tokens (case sensitive) are reserved (in translation phases 7 and 8) for use as
- keywords, and shall not be used otherwise. The keyword _Imaginary is reserved for
-<!--page 77 -->
- specifying imaginary types.<sup><a href="#note70"><b>70)</b></a></sup>
-
-<p><b>Footnotes</b>
-<p><small><a name="note70" href="#note70">70)</a> One possible specification for imaginary types appears in <a href="#G">annex G</a>.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.2" href="#6.4.2">6.4.2 Identifiers</a></h4>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.4.2.1" href="#6.4.2.1">6.4.2.1 General</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          identifier:
-                 identifier-nondigit
-                 identifier identifier-nondigit
-                 identifier digit
-          identifier-nondigit:
-                 nondigit
-                 universal-character-name
-                 other implementation-defined characters
-          nondigit: one of
-                 _ 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
-                     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
-          digit: one of
-                 0 1        2     3    4    5    6     7    8    9
-</pre>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- An identifier is a sequence of nondigit characters (including the underscore _, the
- lowercase and uppercase Latin letters, and other characters) and digits, which designates
- one or more entities as described in <a href="#6.2.1">6.2.1</a>. Lowercase and uppercase letters are distinct.
- There is no specific limit on the maximum length of an identifier.
-<p><!--para 3 -->
- Each universal character name in an identifier shall designate a character whose encoding
- in ISO/IEC 10646 falls into one of the ranges specified in D.1.<sup><a href="#note71"><b>71)</b></a></sup> The initial character
- shall not be a universal character name designating a character whose encoding falls into
- one of the ranges specified in <a href="#D.2">D.2</a>. An implementation may allow multibyte characters
- that are not part of the basic source character set to appear in identifiers; which characters
- and their correspondence to universal character names is implementation-defined.
-<!--page 78 -->
-<p><!--para 4 -->
- When preprocessing tokens are converted to tokens during translation phase 7, if a
- preprocessing token could be converted to either a keyword or an identifier, it is converted
- to a keyword.
-<p><b>Implementation limits</b>
-<p><!--para 5 -->
- As discussed in <a href="#5.2.4.1">5.2.4.1</a>, an implementation may limit the number of significant initial
- characters in an identifier; the limit for an external name (an identifier that has external
- linkage) may be more restrictive than that for an internal name (a macro name or an
- identifier that does not have external linkage). The number of significant characters in an
- identifier is implementation-defined.
-<p><!--para 6 -->
- Any identifiers that differ in a significant character are different identifiers. If two
- identifiers differ only in nonsignificant characters, the behavior is undefined.
-<p><b> Forward references</b>: universal character names (<a href="#6.4.3">6.4.3</a>), macro replacement (<a href="#6.10.3">6.10.3</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note71" href="#note71">71)</a> On systems in which linkers cannot accept extended characters, an encoding of the universal character
- name may be used in forming valid external identifiers. For example, some otherwise unused
- character or sequence of characters may be used to encode the \u in a universal character name.
- Extended characters may produce a long external identifier.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.4.2.2" href="#6.4.2.2">6.4.2.2 Predefined identifiers</a></h5>
-<p><b>Semantics</b>
-<p><!--para 1 -->
- The identifier __func__ shall be implicitly declared by the translator as if,
- immediately following the opening brace of each function definition, the declaration
-<pre>
-          static const char __func__[] = "function-name";
-</pre>
- appeared, where function-name is the name of the lexically-enclosing function.<sup><a href="#note72"><b>72)</b></a></sup>
-<p><!--para 2 -->
- This name is encoded as if the implicit declaration had been written in the source
- character set and then translated into the execution character set as indicated in translation
- phase 5.
-<p><!--para 3 -->
- EXAMPLE        Consider the code fragment:
-<pre>
-          #include <a href="#7.21">&lt;stdio.h&gt;</a>
-          void myfunc(void)
-          {
-                printf("%s\n", __func__);
-                /* ... */
-          }
-</pre>
- Each time the function is called, it will print to the standard output stream:
-<pre>
-          myfunc
-</pre>
-<p><b> Forward references</b>: function definitions (<a href="#6.9.1">6.9.1</a>).
-<!--page 79 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note72" href="#note72">72)</a> Since the name __func__ is reserved for any use by the implementation (<a href="#7.1.3">7.1.3</a>), if any other
- identifier is explicitly declared using the name __func__, the behavior is undefined.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.3" href="#6.4.3">6.4.3 Universal character names</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          universal-character-name:
-                 \u hex-quad
-                 \U hex-quad hex-quad
-          hex-quad:
-                 hexadecimal-digit hexadecimal-digit
-                              hexadecimal-digit hexadecimal-digit
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- A universal character name shall not specify a character whose short identifier is less than
- 00A0 other than 0024 ($), 0040 (@), or 0060 ('), nor one in the range D800 through
- DFFF inclusive.<sup><a href="#note73"><b>73)</b></a></sup>
-<p><b>Description</b>
-<p><!--para 3 -->
- Universal character names may be used in identifiers, character constants, and string
- literals to designate characters that are not in the basic character set.
-<p><b>Semantics</b>
-<p><!--para 4 -->
- The universal character name \Unnnnnnnn designates the character whose eight-digit
- short identifier (as specified by ISO/IEC 10646) is nnnnnnnn.<sup><a href="#note74"><b>74)</b></a></sup> Similarly, the universal
- character name \unnnn designates the character whose four-digit short identifier is nnnn
- (and whose eight-digit short identifier is 0000nnnn).
-<!--page 80 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note73" href="#note73">73)</a> The disallowed characters are the characters in the basic character set and the code positions reserved
- by ISO/IEC 10646 for control characters, the character DELETE, and the S-zone (reserved for use by
- UTF-16).
-</small>
-<p><small><a name="note74" href="#note74">74)</a> Short identifiers for characters were first specified in ISO/IEC 10646-1/AMD9:1997.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.4" href="#6.4.4">6.4.4 Constants</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          constant:
-                 integer-constant
-                 floating-constant
-                 enumeration-constant
-                 character-constant
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each constant shall have a type and the value of a constant shall be in the range of
- representable values for its type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- Each constant has a type, determined by its form and value, as detailed later.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.4.4.1" href="#6.4.4.1">6.4.4.1 Integer constants</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<!--page 81 -->
-<pre>
-          integer-constant:
-                  decimal-constant integer-suffix<sub>opt</sub>
-                  octal-constant integer-suffix<sub>opt</sub>
-                  hexadecimal-constant integer-suffix<sub>opt</sub>
-          decimal-constant:
-                nonzero-digit
-                decimal-constant digit
-          octal-constant:
-                 0
-                 octal-constant octal-digit
-          hexadecimal-constant:
-                hexadecimal-prefix hexadecimal-digit
-                hexadecimal-constant hexadecimal-digit
-          hexadecimal-prefix: one of
-                0x 0X
-          nonzero-digit: one of
-                 1 2 3 4          5     6     7   8    9
-          octal-digit: one of
-                  0 1 2 3         4     5     6   7
-         hexadecimal-digit:   one of
-               0 1 2           3 4     5    6   7     8   9
-               a b c           d e     f
-               A B C           D E     F
-         integer-suffix:
-                 unsigned-suffix long-suffix<sub>opt</sub>
-                 unsigned-suffix long-long-suffix
-                 long-suffix unsigned-suffix<sub>opt</sub>
-                 long-long-suffix unsigned-suffix<sub>opt</sub>
-         unsigned-suffix: one of
-                u U
-         long-suffix: one of
-                l L
-         long-long-suffix: one of
-                ll LL
-</pre>
-<p><b>Description</b>
-<p><!--para 2 -->
- An integer constant begins with a digit, but has no period or exponent part. It may have a
- prefix that specifies its base and a suffix that specifies its type.
-<p><!--para 3 -->
- A decimal constant begins with a nonzero digit and consists of a sequence of decimal
- digits. An octal constant consists of the prefix 0 optionally followed by a sequence of the
- digits 0 through 7 only. A hexadecimal constant consists of the prefix 0x or 0X followed
- by a sequence of the decimal digits and the letters a (or A) through f (or F) with values
- 10 through 15 respectively.
-<p><b>Semantics</b>
-<p><!--para 4 -->
- The value of a decimal constant is computed base 10; that of an octal constant, base 8;
- that of a hexadecimal constant, base 16. The lexically first digit is the most significant.
-<p><!--para 5 -->
- The type of an integer constant is the first of the corresponding list in which its value can
- be represented.
-<!--page 82 -->
-<pre>
-                                                                  Octal or Hexadecimal
-</pre>
- Suffix                       Decimal Constant                           Constant
- none                int                                    int
-<pre>
-                     long int                               unsigned int
-                     long long int                          long int
-                                                            unsigned long int
-                                                            long long int
-                                                            unsigned long long int
-</pre>
- u or U              unsigned int                           unsigned int
-<pre>
-                     unsigned long int                      unsigned long int
-                     unsigned long long int                 unsigned long long int
-</pre>
- l or L              long int                               long int
-<pre>
-                     long long int                          unsigned long int
-                                                            long long int
-                                                            unsigned long long int
-</pre>
- Both u or U         unsigned long int                      unsigned long int
- and l or L          unsigned long long int                 unsigned long long int
- ll or LL            long long int                          long long int
-<pre>
-                                                            unsigned long long int
-</pre>
- Both u or U         unsigned long long int                 unsigned long long int
- and ll or LL
-<p><!--para 6 -->
- If an integer constant cannot be represented by any type in its list, it may have an
- extended integer type, if the extended integer type can represent its value. If all of the
- types in the list for the constant are signed, the extended integer type shall be signed. If
- all of the types in the list for the constant are unsigned, the extended integer type shall be
- unsigned. If the list contains both signed and unsigned types, the extended integer type
- may be signed or unsigned. If an integer constant cannot be represented by any type in
- its list and has no extended integer type, then the integer constant has no type.
-<!--page 83 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.4.4.2" href="#6.4.4.2">6.4.4.2 Floating constants</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<!--page 84 -->
-<pre>
-          floating-constant:
-                 decimal-floating-constant
-                 hexadecimal-floating-constant
-          decimal-floating-constant:
-                fractional-constant exponent-part<sub>opt</sub> floating-suffix<sub>opt</sub>
-                digit-sequence exponent-part floating-suffix<sub>opt</sub>
-          hexadecimal-floating-constant:
-                hexadecimal-prefix hexadecimal-fractional-constant
-                               binary-exponent-part floating-suffix<sub>opt</sub>
-                hexadecimal-prefix hexadecimal-digit-sequence
-                               binary-exponent-part floating-suffix<sub>opt</sub>
-          fractional-constant:
-                  digit-sequence<sub>opt</sub> . digit-sequence
-                  digit-sequence .
-          exponent-part:
-                e sign<sub>opt</sub> digit-sequence
-                E sign<sub>opt</sub> digit-sequence
-          sign: one of
-                 + -
-          digit-sequence:
-                  digit
-                  digit-sequence digit
-          hexadecimal-fractional-constant:
-                hexadecimal-digit-sequence<sub>opt</sub> .
-                               hexadecimal-digit-sequence
-                hexadecimal-digit-sequence .
-          binary-exponent-part:
-                 p sign<sub>opt</sub> digit-sequence
-                 P sign<sub>opt</sub> digit-sequence
-          hexadecimal-digit-sequence:
-                hexadecimal-digit
-                hexadecimal-digit-sequence hexadecimal-digit
-          floating-suffix: one of
-                 f l F L
-</pre>
-<p><b>Description</b>
-<p><!--para 2 -->
- A floating constant has a significand part that may be followed by an exponent part and a
- suffix that specifies its type. The components of the significand part may include a digit
- sequence representing the whole-number part, followed by a period (.), followed by a
- digit sequence representing the fraction part. The components of the exponent part are an
- e, E, p, or P followed by an exponent consisting of an optionally signed digit sequence.
- Either the whole-number part or the fraction part has to be present; for decimal floating
- constants, either the period or the exponent part has to be present.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The significand part is interpreted as a (decimal or hexadecimal) rational number; the
- digit sequence in the exponent part is interpreted as a decimal integer. For decimal
- floating constants, the exponent indicates the power of 10 by which the significand part is
- to be scaled. For hexadecimal floating constants, the exponent indicates the power of 2
- by which the significand part is to be scaled. For decimal floating constants, and also for
- hexadecimal floating constants when FLT_RADIX is not a power of 2, the result is either
- the nearest representable value, or the larger or smaller representable value immediately
- adjacent to the nearest representable value, chosen in an implementation-defined manner.
- For hexadecimal floating constants when FLT_RADIX is a power of 2, the result is
- correctly rounded.
-<p><!--para 4 -->
- An unsuffixed floating constant has type double. If suffixed by the letter f or F, it has
- type float. If suffixed by the letter l or L, it has type long double.
-<p><!--para 5 -->
- Floating constants are converted to internal format as if at translation-time. The
- conversion of a floating constant shall not raise an exceptional condition or a floating-
- point exception at execution time. All floating constants of the same source form<sup><a href="#note75"><b>75)</b></a></sup> shall
- convert to the same internal format with the same value.
-<p><b>Recommended practice</b>
-<p><!--para 6 -->
- The implementation should produce a diagnostic message if a hexadecimal constant
- cannot be represented exactly in its evaluation format; the implementation should then
- proceed with the translation of the program.
-<p><!--para 7 -->
- The translation-time conversion of floating constants should match the execution-time
- conversion of character strings by library functions, such as strtod, given matching
- inputs suitable for both conversions, the same result format, and default execution-time
- rounding.<sup><a href="#note76"><b>76)</b></a></sup>
-<!--page 85 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note75" href="#note75">75)</a> <a href="#1.23">1.23</a>, 1.230, 123e-2, 123e-02, and 1.23L are all different source forms and thus need not
- convert to the same internal format and value.
-</small>
-<p><small><a name="note76" href="#note76">76)</a> The specification for the library functions recommends more accurate conversion than required for
- floating constants (see <a href="#7.22.1.3">7.22.1.3</a>).
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.4.4.3" href="#6.4.4.3">6.4.4.3 Enumeration constants</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          enumeration-constant:
-                identifier
-</pre>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- An identifier declared as an enumeration constant has type int.
-<p><b> Forward references</b>: enumeration specifiers (<a href="#6.7.2.2">6.7.2.2</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.4.4.4" href="#6.4.4.4">6.4.4.4 Character constants</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<!--page 86 -->
-<pre>
-          character-constant:
-                 ' c-char-sequence '
-                 L' c-char-sequence '
-                 u' c-char-sequence '
-                 U' c-char-sequence '
-          c-char-sequence:
-                 c-char
-                 c-char-sequence c-char
-          c-char:
-                    any member of the source character set except
-                                 the single-quote ', backslash \, or new-line character
-                    escape-sequence
-          escape-sequence:
-                 simple-escape-sequence
-                 octal-escape-sequence
-                 hexadecimal-escape-sequence
-                 universal-character-name
-          simple-escape-sequence: one of
-                 \' \" \? \\
-                 \a \b \f \n \r                  \t    \v
-          octal-escape-sequence:
-                  \ octal-digit
-                  \ octal-digit octal-digit
-                  \ octal-digit octal-digit octal-digit
-        hexadecimal-escape-sequence:
-              \x hexadecimal-digit
-              hexadecimal-escape-sequence hexadecimal-digit
-</pre>
-<p><b>Description</b>
-<p><!--para 2 -->
- An integer character constant is a sequence of one or more multibyte characters enclosed
- in single-quotes, as in 'x'. A wide character constant is the same, except prefixed by the
- letter L, u, or U. With a few exceptions detailed later, the elements of the sequence are
- any members of the source character set; they are mapped in an implementation-defined
- manner to members of the execution character set.
-<p><!--para 3 -->
- The single-quote ', the double-quote ", the question-mark ?, the backslash \, and
- arbitrary integer values are representable according to the following table of escape
- sequences:
-<pre>
-       single quote '            \'
-       double quote "            \"
-       question mark ?           \?
-       backslash \               \\
-       octal character           \octal digits
-       hexadecimal character     \x hexadecimal digits
-</pre>
-<p><!--para 4 -->
- The double-quote " and question-mark ? are representable either by themselves or by the
- escape sequences \" and \?, respectively, but the single-quote ' and the backslash \
- shall be represented, respectively, by the escape sequences \' and \\.
-<p><!--para 5 -->
- The octal digits that follow the backslash in an octal escape sequence are taken to be part
- of the construction of a single character for an integer character constant or of a single
- wide character for a wide character constant. The numerical value of the octal integer so
- formed specifies the value of the desired character or wide character.
-<p><!--para 6 -->
- The hexadecimal digits that follow the backslash and the letter x in a hexadecimal escape
- sequence are taken to be part of the construction of a single character for an integer
- character constant or of a single wide character for a wide character constant. The
- numerical value of the hexadecimal integer so formed specifies the value of the desired
- character or wide character.
-<p><!--para 7 -->
- Each octal or hexadecimal escape sequence is the longest sequence of characters that can
- constitute the escape sequence.
-<p><!--para 8 -->
- In addition, characters not in the basic character set are representable by universal
- character names and certain nongraphic characters are representable by escape sequences
- consisting of the backslash \ followed by a lowercase letter: \a, \b, \f, \n, \r, \t,
- and \v.<sup><a href="#note77"><b>77)</b></a></sup>
-<!--page 87 -->
-<p><b>Constraints</b>
-<p><!--para 9 -->
- The value of an octal or hexadecimal escape sequence shall be in the range of
- representable values for the corresponding type:
-<pre>
-        Prefix      Corresponding Type
-        none       unsigned char
-        L          the unsigned type corresponding to wchar_t
-        u          char16_t
-        U          char32_t
-</pre>
-<p><b>Semantics</b>
-<p><!--para 10 -->
- An integer character constant has type int. The value of an integer character constant
- containing a single character that maps to a single-byte execution character is the
- numerical value of the representation of the mapped character interpreted as an integer.
- The value of an integer character constant containing more than one character (e.g.,
- 'ab'), or containing a character or escape sequence that does not map to a single-byte
- execution character, is implementation-defined. If an integer character constant contains
- a single character or escape sequence, its value is the one that results when an object with
- type char whose value is that of the single character or escape sequence is converted to
- type int.
-<p><!--para 11 -->
- A wide character constant prefixed by the letter L has type wchar_t, an integer type
- defined in the <a href="#7.19">&lt;stddef.h&gt;</a> header; a wide character constant prefixed by the letter u or
- U has type char16_t or char32_t, respectively, unsigned integer types defined in the
- <a href="#7.27">&lt;uchar.h&gt;</a> header. The value of a wide character constant containing a single
- multibyte character that maps to a single member of the extended execution character set
- is the wide character corresponding to that multibyte character, as defined by the
- mbtowc, mbrtoc16, or mbrtoc32 function as appropriate for its type, with an
- implementation-defined current locale. The value of a wide character constant containing
- more than one multibyte character or a single multibyte character that maps to multiple
- members of the extended execution character set, or containing a multibyte character or
- escape sequence not represented in the extended execution character set, is
- implementation-defined.
-<p><!--para 12 -->
- EXAMPLE 1      The construction '\0' is commonly used to represent the null character.
-<p><!--para 13 -->
- EXAMPLE 2 Consider implementations that use two's complement representation for integers and eight
- bits for objects that have type char. In an implementation in which type char has the same range of
- values as signed char, the integer character constant '\xFF' has the value -1; if type char has the
- same range of values as unsigned char, the character constant '\xFF' has the value +255.
-<!--page 88 -->
-<p><!--para 14 -->
- EXAMPLE 3 Even if eight bits are used for objects that have type char, the construction '\x123'
- specifies an integer character constant containing only one character, since a hexadecimal escape sequence
- is terminated only by a non-hexadecimal character. To specify an integer character constant containing the
- two characters whose values are '\x12' and '3', the construction '\0223' may be used, since an octal
- escape sequence is terminated after three octal digits. (The value of this two-character integer character
- constant is implementation-defined.)
-<p><!--para 15 -->
- EXAMPLE 4 Even if 12 or more bits are used for objects that have type wchar_t, the construction
- L'\1234' specifies the implementation-defined value that results from the combination of the values
- 0123 and '4'.
-<p><b> Forward references</b>: common definitions <a href="#7.19">&lt;stddef.h&gt;</a> (<a href="#7.19">7.19</a>), the mbtowc function
- (<a href="#7.22.7.2">7.22.7.2</a>), Unicode utilities <a href="#7.27">&lt;uchar.h&gt;</a> (<a href="#7.27">7.27</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note77" href="#note77">77)</a> The semantics of these characters were discussed in <a href="#5.2.2">5.2.2</a>. If any other character follows a backslash,
- the result is not a token and a diagnostic is required. See ''future language directions'' (<a href="#6.11.4">6.11.4</a>).
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.5" href="#6.4.5">6.4.5 String literals</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          string-literal:
-                  encoding-prefix<sub>opt</sub> " s-char-sequence<sub>opt</sub> "
-          encoding-prefix:
-                 u8
-                 u
-                 U
-                 L
-          s-char-sequence:
-                 s-char
-                 s-char-sequence s-char
-          s-char:
-                    any member of the source character set except
-                                 the double-quote ", backslash \, or new-line character
-                    escape-sequence
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- A sequence of adjacent string literal tokens shall not include both a wide string literal and
- a UTF-8 string literal.
-<p><b>Description</b>
-<p><!--para 3 -->
- A character string literal is a sequence of zero or more multibyte characters enclosed in
- double-quotes, as in "xyz". A UTF-8 string literal is the same, except prefixed by u8.
- A wide string literal is the same, except prefixed by the letter L, u, or U.
-<p><!--para 4 -->
- The same considerations apply to each element of the sequence in a string literal as if it
- were in an integer character constant (for a character or UTF-8 string literal) or a wide
- character constant (for a wide string literal), except that the single-quote ' is
- representable either by itself or by the escape sequence \', but the double-quote " shall
-<!--page 89 -->
- be represented by the escape sequence \".
-<p><b>Semantics</b>
-<p><!--para 5 -->
- In translation phase 6, the multibyte character sequences specified by any sequence of
- adjacent character and identically-prefixed string literal tokens are concatenated into a
- single multibyte character sequence. If any of the tokens has an encoding prefix, the
- resulting multibyte character sequence is treated as having the same prefix; otherwise, it
- is treated as a character string literal. Whether differently-prefixed wide string literal
- tokens can be concatenated and, if so, the treatment of the resulting multibyte character
- sequence are implementation-defined.
-<p><!--para 6 -->
- In translation phase 7, a byte or code of value zero is appended to each multibyte
- character sequence that results from a string literal or literals.<sup><a href="#note78"><b>78)</b></a></sup> The multibyte character
- sequence is then used to initialize an array of static storage duration and length just
- sufficient to contain the sequence. For character string literals, the array elements have
- type char, and are initialized with the individual bytes of the multibyte character
- sequence. For UTF-8 string literals, the array elements have type char, and are
- initialized with the characters of the multibyte character sequence, as encoded in UTF-8.
- For wide string literals prefixed by the letter L, the array elements have type wchar_t
- and are initialized with the sequence of wide characters corresponding to the multibyte
- character sequence, as defined by the mbstowcs function with an implementation-
- defined current locale. For wide string literals prefixed by the letter u or U, the array
- elements have type char16_t or char32_t, respectively, and are initialized with the
- sequence of wide characters corresponding to the multibyte character sequence, as
- defined by successive calls to the mbrtoc16, or mbrtoc32 function as appropriate for
- its type, with an implementation-defined current locale. The value of a string literal
- containing a multibyte character or escape sequence not represented in the execution
- character set is implementation-defined.
-<p><!--para 7 -->
- It is unspecified whether these arrays are distinct provided their elements have the
- appropriate values. If the program attempts to modify such an array, the behavior is
- undefined.
-<p><!--para 8 -->
- EXAMPLE 1      This pair of adjacent character string literals
-<pre>
-          "\x12" "3"
-</pre>
- produces a single character string literal containing the two characters whose values are '\x12' and '3',
- because escape sequences are converted into single members of the execution character set just prior to
- adjacent string literal concatenation.
-<p><!--para 9 -->
- EXAMPLE 2      Each of the sequences of adjacent string literal tokens
-<!--page 90 -->
-<pre>
-          "a" "b" L"c"
-          "a" L"b" "c"
-          L"a" "b" L"c"
-          L"a" L"b" L"c"
-</pre>
- is equivalent to the string literal
-<pre>
-          L"abc"
-</pre>
- Likewise, each of the sequences
-<pre>
-          "a" "b" u"c"
-          "a" u"b" "c"
-          u"a" "b" u"c"
-          u"a" u"b" u"c"
-</pre>
- is equivalent to
-<pre>
-          u"abc"
-</pre>
-<p><b> Forward references</b>: common definitions <a href="#7.19">&lt;stddef.h&gt;</a> (<a href="#7.19">7.19</a>), the mbstowcs
- function (<a href="#7.22.8.1">7.22.8.1</a>), Unicode utilities <a href="#7.27">&lt;uchar.h&gt;</a> (<a href="#7.27">7.27</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note78" href="#note78">78)</a> A string literal need not be a string (see <a href="#7.1.1">7.1.1</a>), because a null character may be embedded in it by a
- \0 escape sequence.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.6" href="#6.4.6">6.4.6 Punctuators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          punctuator: one of
-                 [ ] ( ) { } . -&gt;
-                 ++ -- &amp; * + - ~ !
-                 / % &lt;&lt; &gt;&gt; &lt; &gt; &lt;= &gt;=                         ==    !=    ^    |   &amp;&amp;   ||
-                 ? : ; ...
-                 = *= /= %= += -= &lt;&lt;=                        &gt;&gt;=    &amp;=       ^=   |=
-                 , # ##
-                 &lt;: :&gt; &lt;% %&gt; %: %:%:
-</pre>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- A punctuator is a symbol that has independent syntactic and semantic significance.
- Depending on context, it may specify an operation to be performed (which in turn may
- yield a value or a function designator, produce a side effect, or some combination thereof)
- in which case it is known as an operator (other forms of operator also exist in some
- contexts). An operand is an entity on which an operator acts.
-<!--page 91 -->
-<p><!--para 3 -->
- In all aspects of the language, the six tokens<sup><a href="#note79"><b>79)</b></a></sup>
-<pre>
-          &lt;:    :&gt;      &lt;%    %&gt;     %:     %:%:
-</pre>
- behave, respectively, the same as the six tokens
-<pre>
-          [     ]       {     }      #      ##
-</pre>
- except for their spelling.<sup><a href="#note80"><b>80)</b></a></sup>
-<p><b> Forward references</b>: expressions (<a href="#6.5">6.5</a>), declarations (<a href="#6.7">6.7</a>), preprocessing directives
- (<a href="#6.10">6.10</a>), statements (<a href="#6.8">6.8</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note79" href="#note79">79)</a> These tokens are sometimes called ''digraphs''.
-</small>
-<p><small><a name="note80" href="#note80">80)</a> Thus [ and &lt;: behave differently when ''stringized'' (see <a href="#6.10.3.2">6.10.3.2</a>), but can otherwise be freely
- interchanged.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.7" href="#6.4.7">6.4.7 Header names</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          header-name:
-                 &lt; h-char-sequence &gt;
-                 " q-char-sequence "
-          h-char-sequence:
-                 h-char
-                 h-char-sequence h-char
-          h-char:
-                    any member of the source character set except
-                                 the new-line character and &gt;
-          q-char-sequence:
-                 q-char
-                 q-char-sequence q-char
-          q-char:
-                    any member of the source character set except
-                                 the new-line character and "
-</pre>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- The sequences in both forms of header names are mapped in an implementation-defined
- manner to headers or external source file names as specified in <a href="#6.10.2">6.10.2</a>.
-<p><!--para 3 -->
- If the characters ', \, ", //, or /* occur in the sequence between the &lt; and &gt; delimiters,
- the behavior is undefined. Similarly, if the characters ', \, //, or /* occur in the
-<!--page 92 -->
- sequence between the " delimiters, the behavior is undefined.<sup><a href="#note81"><b>81)</b></a></sup> Header name
- preprocessing tokens are recognized only within #include preprocessing directives and
- in implementation-defined locations within #pragma directives.<sup><a href="#note82"><b>82)</b></a></sup>
-<p><!--para 4 -->
- EXAMPLE       The following sequence of characters:
-<pre>
-          0x3&lt;1/a.h&gt;1e2
-          #include &lt;1/a.h&gt;
-          #define const.member@$
-</pre>
- forms the following sequence of preprocessing tokens (with each individual preprocessing token delimited
- by a { on the left and a } on the right).
-<pre>
-          {0x3}{&lt;}{1}{/}{a}{.}{h}{&gt;}{1e2}
-          {#}{include} {&lt;1/a.h&gt;}
-          {#}{define} {const}{.}{member}{@}{$}
-</pre>
-<p><b> Forward references</b>: source file inclusion (<a href="#6.10.2">6.10.2</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note81" href="#note81">81)</a> Thus, sequences of characters that resemble escape sequences cause undefined behavior.
-</small>
-<p><small><a name="note82" href="#note82">82)</a> For an example of a header name preprocessing token used in a #pragma directive, see <a href="#6.10.9">6.10.9</a>.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.8" href="#6.4.8">6.4.8 Preprocessing numbers</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          pp-number:
-                digit
-                . digit
-                pp-number       digit
-                pp-number       identifier-nondigit
-                pp-number       e sign
-                pp-number       E sign
-                pp-number       p sign
-                pp-number       P sign
-                pp-number       .
-</pre>
-<p><b>Description</b>
-<p><!--para 2 -->
- A preprocessing number begins with a digit optionally preceded by a period (.) and may
- be followed by valid identifier characters and the character sequences e+, e-, E+, E-,
- p+, p-, P+, or P-.
-<p><!--para 3 -->
- Preprocessing number tokens lexically include all floating and integer constant tokens.
-<p><b>Semantics</b>
-<p><!--para 4 -->
- A preprocessing number does not have type or a value; it acquires both after a successful
- conversion (as part of translation phase 7) to a floating constant token or an integer
- constant token.
-<!--page 93 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.4.9" href="#6.4.9">6.4.9 Comments</a></h4>
-<p><!--para 1 -->
- Except within a character constant, a string literal, or a comment, the characters /*
- introduce a comment. The contents of such a comment are examined only to identify
- multibyte characters and to find the characters */ that terminate it.<sup><a href="#note83"><b>83)</b></a></sup>
-<p><!--para 2 -->
- Except within a character constant, a string literal, or a comment, the characters //
- introduce a comment that includes all multibyte characters up to, but not including, the
- next new-line character. The contents of such a comment are examined only to identify
- multibyte characters and to find the terminating new-line character.
-<p><!--para 3 -->
- EXAMPLE
-<pre>
-          "a//b"                             //   four-character string literal
-          #include "//e"                     //   undefined behavior
-          // */                              //   comment, not syntax error
-          f = g/**//h;                       //   equivalent to f = g / h;
-          //\
-          i();                               // part of a two-line comment
-          /\
-          / j();                             // part of a two-line comment
-          #define glue(x,y) x##y
-          glue(/,/) k();                     // syntax error, not comment
-          /*//*/ l();                        // equivalent to l();
-          m = n//**/o
-             + p;                            // equivalent to m = n + p;
-</pre>
-<!--page 94 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note83" href="#note83">83)</a> Thus, /* ... */ comments do not nest.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="6.5" href="#6.5">6.5 Expressions</a></h3>
-<p><!--para 1 -->
- An expression is a sequence of operators and operands that specifies computation of a
- value, or that designates an object or a function, or that generates side effects, or that
- performs a combination thereof. The value computations of the operands of an operator
- are sequenced before the value computation of the result of the operator.
-<p><!--para 2 -->
- If a side effect on a scalar object is unsequenced relative to either a different side effect
- on the same scalar object or a value computation using the value of the same scalar
- object, the behavior is undefined. If there are multiple allowable orderings of the
- subexpressions of an expression, the behavior is undefined if such an unsequenced side
- effect occurs in any of the orderings.<sup><a href="#note84"><b>84)</b></a></sup>
-<p><!--para 3 -->
- The grouping of operators and operands is indicated by the syntax.<sup><a href="#note85"><b>85)</b></a></sup> Except as specified
- later, side effects and value computations of subexpressions are unsequenced.<sup><a href="#note86"><b>86)</b></a></sup>         *
-<p><!--para 4 -->
- Some operators (the unary operator ~, and the binary operators &lt;&lt;, &gt;&gt;, &amp;, ^, and |,
- collectively described as bitwise operators) are required to have operands that have
- integer type. These operators yield values that depend on the internal representations of
- integers, and have implementation-defined and undefined aspects for signed types.
-<p><!--para 5 -->
- If an exceptional condition occurs during the evaluation of an expression (that is, if the
- result is not mathematically defined or not in the range of representable values for its
- type), the behavior is undefined.
-<!--page 95 -->
-<p><!--para 6 -->
- The effective type of an object for an access to its stored value is the declared type of the
- object, if any.<sup><a href="#note87"><b>87)</b></a></sup> If a value is stored into an object having no declared type through an
- lvalue having a type that is not a character type, then the type of the lvalue becomes the
- effective type of the object for that access and for subsequent accesses that do not modify
- the stored value. If a value is copied into an object having no declared type using
- memcpy or memmove, or is copied as an array of character type, then the effective type
- of the modified object for that access and for subsequent accesses that do not modify the
- value is the effective type of the object from which the value is copied, if it has one. For
- all other accesses to an object having no declared type, the effective type of the object is
- simply the type of the lvalue used for the access.
-<p><!--para 7 -->
- An object shall have its stored value accessed only by an lvalue expression that has one of
- the following types:<sup><a href="#note88"><b>88)</b></a></sup>
-<ul>
-<li>  a type compatible with the effective type of the object,
-<li>  a qualified version of a type compatible with the effective type of the object,
-<li>  a type that is the signed or unsigned type corresponding to the effective type of the
- object,
-<li>  a type that is the signed or unsigned type corresponding to a qualified version of the
- effective type of the object,
-<li>  an aggregate or union type that includes one of the aforementioned types among its
- members (including, recursively, a member of a subaggregate or contained union), or
-<li>  a character type.
-</ul>
-<p><!--para 8 -->
- A floating expression may be contracted, that is, evaluated as though it were a single
- operation, thereby omitting rounding errors implied by the source code and the
- expression evaluation method.<sup><a href="#note89"><b>89)</b></a></sup> The FP_CONTRACT pragma in <a href="#7.12">&lt;math.h&gt;</a> provides a
- way to disallow contracted expressions. Otherwise, whether and how expressions are
- contracted is implementation-defined.<sup><a href="#note90"><b>90)</b></a></sup>
-<p><b> Forward references</b>: the FP_CONTRACT pragma (<a href="#7.12.2">7.12.2</a>), copying functions (<a href="#7.23.2">7.23.2</a>).
-<!--page 96 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note84" href="#note84">84)</a> This paragraph renders undefined statement expressions such as
-
-<pre>
-           i = ++i + 1;
-           a[i++] = i;
-</pre>
-  while allowing
-
-<pre>
-           i = i + 1;
-           a[i] = i;
-</pre>
-</small>
-<p><small><a name="note85" href="#note85">85)</a> The syntax specifies the precedence of operators in the evaluation of an expression, which is the same
- as the order of the major subclauses of this subclause, highest precedence first. Thus, for example, the
- expressions allowed as the operands of the binary + operator (<a href="#6.5.6">6.5.6</a>) are those expressions defined in
- <a href="#6.5.1">6.5.1</a> through <a href="#6.5.6">6.5.6</a>. The exceptions are cast expressions (<a href="#6.5.4">6.5.4</a>) as operands of unary operators
- (<a href="#6.5.3">6.5.3</a>), and an operand contained between any of the following pairs of operators: grouping
- parentheses () (<a href="#6.5.1">6.5.1</a>), subscripting brackets [] (<a href="#6.5.2.1">6.5.2.1</a>), function-call parentheses () (<a href="#6.5.2.2">6.5.2.2</a>), and
- the conditional operator ? : (<a href="#6.5.15">6.5.15</a>).
-  Within each major subclause, the operators have the same precedence. Left- or right-associativity is
-  indicated in each subclause by the syntax for the expressions discussed therein.
-</small>
-<p><small><a name="note86" href="#note86">86)</a> In an expression that is evaluated more than once during the execution of a program, unsequenced and
- indeterminately sequenced evaluations of its subexpressions need not be performed consistently in
- different evaluations.
-</small>
-<p><small><a name="note87" href="#note87">87)</a> Allocated objects have no declared type.
-</small>
-<p><small><a name="note88" href="#note88">88)</a> The intent of this list is to specify those circumstances in which an object may or may not be aliased.
-</small>
-<p><small><a name="note89" href="#note89">89)</a> The intermediate operations in the contracted expression are evaluated as if to infinite precision and
- range, while the final operation is rounded to the format determined by the expression evaluation
- method. A contracted expression might also omit the raising of floating-point exceptions.
-</small>
-<p><small><a name="note90" href="#note90">90)</a> This license is specifically intended to allow implementations to exploit fast machine instructions that
- combine multiple C operators. As contractions potentially undermine predictability, and can even
- decrease accuracy for containing expressions, their use needs to be well-defined and clearly
- documented.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.1" href="#6.5.1">6.5.1 Primary expressions</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          primary-expression:
-                 identifier
-                 constant
-                 string-literal
-                 ( expression )
-                 generic-selection
-</pre>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- An identifier is a primary expression, provided it has been declared as designating an
- object (in which case it is an lvalue) or a function (in which case it is a function
- designator).<sup><a href="#note91"><b>91)</b></a></sup>
-<p><!--para 3 -->
- A constant is a primary expression. Its type depends on its form and value, as detailed in
- <a href="#6.4.4">6.4.4</a>.
-<p><!--para 4 -->
- A string literal is a primary expression. It is an lvalue with type as detailed in <a href="#6.4.5">6.4.5</a>.
-<p><!--para 5 -->
- A parenthesized expression is a primary expression. Its type and value are identical to
- those of the unparenthesized expression. It is an lvalue, a function designator, or a void
- expression if the unparenthesized expression is, respectively, an lvalue, a function
- designator, or a void expression.
-<p><b> Forward references</b>: declarations (<a href="#6.7">6.7</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note91" href="#note91">91)</a> Thus, an undeclared identifier is a violation of the syntax.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.1.1" href="#6.5.1.1">6.5.1.1 Generic selection</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          generic-selection:
-                 _Generic ( assignment-expression , generic-assoc-list )
-          generic-assoc-list:
-                 generic-association
-                 generic-assoc-list , generic-association
-          generic-association:
-                 type-name : assignment-expression
-                 default : assignment-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- A generic selection shall have no more than one default generic association. The type
- name in a generic association shall specify a complete object type other than a variably
-<!--page 97 -->
- modified type. No two generic associations in the same generic selection shall specify
- compatible types. The controlling expression of a generic selection shall have type
- compatible with at most one of the types named in its generic association list. If a
- generic selection has no default generic association, its controlling expression shall
- have type compatible with exactly one of the types named in its generic association list.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The controlling expression of a generic selection is not evaluated. If a generic selection
- has a generic association with a type name that is compatible with the type of the
- controlling expression, then the result expression of the generic selection is the
- expression in that generic association. Otherwise, the result expression of the generic
- selection is the expression in the default generic association. None of the expressions
- from any other generic association of the generic selection is evaluated.
-<p><!--para 4 -->
- The type and value of a generic selection are identical to those of its result expression. It
- is an lvalue, a function designator, or a void expression if its result expression is,
- respectively, an lvalue, a function designator, or a void expression.
-<p><!--para 5 -->
- EXAMPLE      The cbrt type-generic macro could be implemented as follows:
-<pre>
-          #define cbrt(X) _Generic((X),                                      \
-                                  long double: cbrtl,                        \
-                                  default: cbrt,                             \
-                                  float: cbrtf                               \
-                                  )(X)
-</pre>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.2" href="#6.5.2">6.5.2 Postfix operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<!--page 98 -->
-<pre>
-          postfix-expression:
-                 primary-expression
-                 postfix-expression [ expression ]
-                 postfix-expression ( argument-expression-list<sub>opt</sub> )
-                 postfix-expression . identifier
-                 postfix-expression -&gt; identifier
-                 postfix-expression ++
-                 postfix-expression --
-                 ( type-name ) { initializer-list }
-                 ( type-name ) { initializer-list , }
-          argument-expression-list:
-                assignment-expression
-                argument-expression-list , assignment-expression
-</pre>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.2.1" href="#6.5.2.1">6.5.2.1 Array subscripting</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- One of the expressions shall have type ''pointer to complete object type'', the other
- expression shall have integer type, and the result has type ''type''.
-<p><b>Semantics</b>
-<p><!--para 2 -->
- A postfix expression followed by an expression in square brackets [] is a subscripted
- designation of an element of an array object. The definition of the subscript operator []
- is that E1[E2] is identical to (*((E1)+(E2))). Because of the conversion rules that
- apply to the binary + operator, if E1 is an array object (equivalently, a pointer to the
- initial element of an array object) and E2 is an integer, E1[E2] designates the E2-th
- element of E1 (counting from zero).
-<p><!--para 3 -->
- Successive subscript operators designate an element of a multidimensional array object.
- If E is an n-dimensional array (n &gt;= 2) with dimensions i x j x . . . x k, then E (used as
- other than an lvalue) is converted to a pointer to an (n - 1)-dimensional array with
- dimensions j x . . . x k. If the unary * operator is applied to this pointer explicitly, or
- implicitly as a result of subscripting, the result is the referenced (n - 1)-dimensional
- array, which itself is converted into a pointer if used as other than an lvalue. It follows
- from this that arrays are stored in row-major order (last subscript varies fastest).
-<p><!--para 4 -->
- EXAMPLE        Consider the array object defined by the declaration
-<pre>
-          int x[3][5];
-</pre>
- Here x is a 3 x 5 array of ints; more precisely, x is an array of three element objects, each of which is an
- array of five ints. In the expression x[i], which is equivalent to (*((x)+(i))), x is first converted to
- a pointer to the initial array of five ints. Then i is adjusted according to the type of x, which conceptually
- entails multiplying i by the size of the object to which the pointer points, namely an array of five int
- objects. The results are added and indirection is applied to yield an array of five ints. When used in the
- expression x[i][j], that array is in turn converted to a pointer to the first of the ints, so x[i][j]
- yields an int.
-<p><b> Forward references</b>: additive operators (<a href="#6.5.6">6.5.6</a>), address and indirection operators
- (<a href="#6.5.3.2">6.5.3.2</a>), array declarators (<a href="#6.7.6.2">6.7.6.2</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.2.2" href="#6.5.2.2">6.5.2.2 Function calls</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- The expression that denotes the called function<sup><a href="#note92"><b>92)</b></a></sup> shall have type pointer to function
- returning void or returning a complete object type other than an array type.
-<p><!--para 2 -->
- If the expression that denotes the called function has a type that includes a prototype, the
- number of arguments shall agree with the number of parameters. Each argument shall
-<!--page 99 -->
- have a type such that its value may be assigned to an object with the unqualified version
- of the type of its corresponding parameter.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- A postfix expression followed by parentheses () containing a possibly empty, comma-
- separated list of expressions is a function call. The postfix expression denotes the called
- function. The list of expressions specifies the arguments to the function.
-<p><!--para 4 -->
- An argument may be an expression of any complete object type. In preparing for the call
- to a function, the arguments are evaluated, and each parameter is assigned the value of the
- corresponding argument.<sup><a href="#note93"><b>93)</b></a></sup>
-<p><!--para 5 -->
- If the expression that denotes the called function has type pointer to function returning an
- object type, the function call expression has the same type as that object type, and has the
- value determined as specified in <a href="#6.8.6.4">6.8.6.4</a>. Otherwise, the function call has type void.         *
-<p><!--para 6 -->
- If the expression that denotes the called function has a type that does not include a
- prototype, the integer promotions are performed on each argument, and arguments that
- have type float are promoted to double. These are called the default argument
- promotions. If the number of arguments does not equal the number of parameters, the
- behavior is undefined. If the function is defined with a type that includes a prototype, and
- either the prototype ends with an ellipsis (, ...) or the types of the arguments after
- promotion are not compatible with the types of the parameters, the behavior is undefined.
- If the function is defined with a type that does not include a prototype, and the types of
- the arguments after promotion are not compatible with those of the parameters after
- promotion, the behavior is undefined, except for the following cases:
-<ul>
-<li>  one promoted type is a signed integer type, the other promoted type is the
- corresponding unsigned integer type, and the value is representable in both types;
-<li>  both types are pointers to qualified or unqualified versions of a character type or
- void.
-</ul>
-<p><!--para 7 -->
- If the expression that denotes the called function has a type that does include a prototype,
- the arguments are implicitly converted, as if by assignment, to the types of the
- corresponding parameters, taking the type of each parameter to be the unqualified version
- of its declared type. The ellipsis notation in a function prototype declarator causes
- argument type conversion to stop after the last declared parameter. The default argument
- promotions are performed on trailing arguments.
-<!--page 100 -->
-<p><!--para 8 -->
- No other conversions are performed implicitly; in particular, the number and types of
- arguments are not compared with those of the parameters in a function definition that
- does not include a function prototype declarator.
-<p><!--para 9 -->
- If the function is defined with a type that is not compatible with the type (of the
- expression) pointed to by the expression that denotes the called function, the behavior is
- undefined.
-<p><!--para 10 -->
- There is a sequence point after the evaluations of the function designator and the actual
- arguments but before the actual call. Every evaluation in the calling function (including
- other function calls) that is not otherwise specifically sequenced before or after the
- execution of the body of the called function is indeterminately sequenced with respect to
- the execution of the called function.<sup><a href="#note94"><b>94)</b></a></sup>
-<p><!--para 11 -->
- Recursive function calls shall be permitted, both directly and indirectly through any chain
- of other functions.
-<p><!--para 12 -->
- EXAMPLE        In the function call
-<pre>
-          (*pf[f1()]) (f2(), f3() + f4())
-</pre>
- the functions f1, f2, f3, and f4 may be called in any order. All side effects have to be completed before
- the function pointed to by pf[f1()] is called.
-<p><b> Forward references</b>: function declarators (including prototypes) (<a href="#6.7.6.3">6.7.6.3</a>), function
- definitions (<a href="#6.9.1">6.9.1</a>), the return statement (<a href="#6.8.6.4">6.8.6.4</a>), simple assignment (<a href="#6.5.16.1">6.5.16.1</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note92" href="#note92">92)</a> Most often, this is the result of converting an identifier that is a function designator.
-</small>
-<p><small><a name="note93" href="#note93">93)</a> A function may change the values of its parameters, but these changes cannot affect the values of the
- arguments. On the other hand, it is possible to pass a pointer to an object, and the function may
- change the value of the object pointed to. A parameter declared to have array or function type is
- adjusted to have a pointer type as described in <a href="#6.9.1">6.9.1</a>.
-</small>
-<p><small><a name="note94" href="#note94">94)</a> In other words, function executions do not ''interleave'' with each other.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.2.3" href="#6.5.2.3">6.5.2.3 Structure and union members</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- The first operand of the . operator shall have an atomic, qualified, or unqualified
- structure or union type, and the second operand shall name a member of that type.
-<p><!--para 2 -->
- The first operand of the -&gt; operator shall have type ''pointer to atomic, qualified, or
- unqualified structure'' or ''pointer to atomic, qualified, or unqualified union'', and the
- second operand shall name a member of the type pointed to.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- A postfix expression followed by the . operator and an identifier designates a member of
- a structure or union object. The value is that of the named member,<sup><a href="#note95"><b>95)</b></a></sup> and is an lvalue if
- the first expression is an lvalue. If the first expression has qualified type, the result has
- the so-qualified version of the type of the designated member.
-<!--page 101 -->
-<p><!--para 4 -->
- A postfix expression followed by the -&gt; operator and an identifier designates a member
- of a structure or union object. The value is that of the named member of the object to
- which the first expression points, and is an lvalue.<sup><a href="#note96"><b>96)</b></a></sup> If the first expression is a pointer to
- a qualified type, the result has the so-qualified version of the type of the designated
- member.
-<p><!--para 5 -->
- Accessing a member of an atomic structure or union object results in undefined
- behavior.<sup><a href="#note97"><b>97)</b></a></sup>
-<p><!--para 6 -->
- One special guarantee is made in order to simplify the use of unions: if a union contains
- several structures that share a common initial sequence (see below), and if the union
- object currently contains one of these structures, it is permitted to inspect the common
- initial part of any of them anywhere that a declaration of the completed type of the union
- is visible. Two structures share a common initial sequence if corresponding members
- have compatible types (and, for bit-fields, the same widths) for a sequence of one or more
- initial members.
-<p><!--para 7 -->
- EXAMPLE 1 If f is a function returning a structure or union, and x is a member of that structure or
- union, f().x is a valid postfix expression but is not an lvalue.
-<p><!--para 8 -->
- EXAMPLE 2       In:
-<pre>
-          struct s { int i; const int ci; };
-          struct s s;
-          const struct s cs;
-          volatile struct s vs;
-</pre>
- the various members have the types:
-<pre>
-          s.i          int
-          s.ci         const int
-          cs.i         const int
-          cs.ci        const int
-          vs.i         volatile int
-          vs.ci        volatile const int
-</pre>
-<!--page 102 -->
-<p><!--para 9 -->
- EXAMPLE 3       The following is a valid fragment:
-<pre>
-          union {
-                  struct {
-                        int      alltypes;
-                  } n;
-                  struct {
-                        int      type;
-                        int      intnode;
-                  } ni;
-                  struct {
-                        int      type;
-                        double doublenode;
-                  } nf;
-          } u;
-          u.nf.type = 1;
-          u.nf.doublenode = <a href="#3.14">3.14</a>;
-          /* ... */
-          if (u.n.alltypes == 1)
-                  if (sin(u.nf.doublenode) == 0.0)
-                        /* ... */
-</pre>
- The following is not a valid fragment (because the union type is not visible within function f):
-<pre>
-          struct t1 { int m; };
-          struct t2 { int m; };
-          int f(struct t1 *p1, struct t2 *p2)
-          {
-                if (p1-&gt;m &lt; 0)
-                        p2-&gt;m = -p2-&gt;m;
-                return p1-&gt;m;
-          }
-          int g()
-          {
-                union {
-                        struct t1 s1;
-                        struct t2 s2;
-                } u;
-                /* ... */
-                return f(&amp;u.s1, &amp;u.s2);
-          }
-</pre>
-<p><b> Forward references</b>: address and indirection operators (<a href="#6.5.3.2">6.5.3.2</a>), structure and union
- specifiers (<a href="#6.7.2.1">6.7.2.1</a>).
-<!--page 103 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note95" href="#note95">95)</a> If the member used to read the contents of a union object is not the same as the member last used to
- store a value in the object, the appropriate part of the object representation of the value is reinterpreted
- as an object representation in the new type as described in <a href="#6.2.6">6.2.6</a> (a process sometimes called ''type
- punning''). This might be a trap representation.
-</small>
-<p><small><a name="note96" href="#note96">96)</a> If &amp;E is a valid pointer expression (where &amp; is the ''address-of '' operator, which generates a pointer to
- its operand), the expression (&amp;E)-&gt;MOS is the same as E.MOS.
-</small>
-<p><small><a name="note97" href="#note97">97)</a> For example, a data race would occur if access to the entire structure or union in one thread conflicts
- with access to a member from another thread, where at least one access is a modification. Members
- can be safely accessed using a non-atomic object which is assigned to or from the atomic object.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.2.4" href="#6.5.2.4">6.5.2.4 Postfix increment and decrement operators</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- The operand of the postfix increment or decrement operator shall have atomic, qualified,
- or unqualified real or pointer type, and shall be a modifiable lvalue.
-<p><b>Semantics</b>
-<p><!--para 2 -->
- The result of the postfix ++ operator is the value of the operand. As a side effect, the
- value of the operand object is incremented (that is, the value 1 of the appropriate type is
- added to it). See the discussions of additive operators and compound assignment for
- information on constraints, types, and conversions and the effects of operations on
- pointers. The value computation of the result is sequenced before the side effect of
- updating the stored value of the operand. With respect to an indeterminately-sequenced
- function call, the operation of postfix ++ is a single evaluation. Postfix ++ on an object
- with atomic type is a read-modify-write operation with memory_order_seq_cst
- memory order semantics.<sup><a href="#note98"><b>98)</b></a></sup>
-<p><!--para 3 -->
- The postfix -- operator is analogous to the postfix ++ operator, except that the value of
- the operand is decremented (that is, the value 1 of the appropriate type is subtracted from
- it).
-<p><b> Forward references</b>: additive operators (<a href="#6.5.6">6.5.6</a>), compound assignment (<a href="#6.5.16.2">6.5.16.2</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note98" href="#note98">98)</a> Where a pointer to an atomic object can be formed, this is equivalent to the following code sequence
- where T is the type of E:
-
-<pre>
-          T tmp;
-          T result = E;
-          do {
-                 tmp = result + 1;
-          } while (!atomic_compare_exchange_strong(&amp;E, &amp;result, tmp));
-</pre>
-  with result being the result of the operation.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.2.5" href="#6.5.2.5">6.5.2.5 Compound literals</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- The type name shall specify a complete object type or an array of unknown size, but not a
- variable length array type.
-<p><!--para 2 -->
- All the constraints for initializer lists in <a href="#6.7.9">6.7.9</a> also apply to compound literals.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- A postfix expression that consists of a parenthesized type name followed by a brace-
- enclosed list of initializers is a compound literal. It provides an unnamed object whose
- value is given by the initializer list.<sup><a href="#note99"><b>99)</b></a></sup>
-<!--page 104 -->
-<p><!--para 4 -->
- If the type name specifies an array of unknown size, the size is determined by the
- initializer list as specified in <a href="#6.7.9">6.7.9</a>, and the type of the compound literal is that of the
- completed array type. Otherwise (when the type name specifies an object type), the type
- of the compound literal is that specified by the type name. In either case, the result is an
- lvalue.
-<p><!--para 5 -->
- The value of the compound literal is that of an unnamed object initialized by the
- initializer list. If the compound literal occurs outside the body of a function, the object
- has static storage duration; otherwise, it has automatic storage duration associated with
- the enclosing block.
-<p><!--para 6 -->
- All the semantic rules for initializer lists in <a href="#6.7.9">6.7.9</a> also apply to compound literals.<sup><a href="#note100"><b>100)</b></a></sup>
-<p><!--para 7 -->
- String literals, and compound literals with const-qualified types, need not designate
- distinct objects.<sup><a href="#note101"><b>101)</b></a></sup>
-<p><!--para 8 -->
- EXAMPLE 1       The file scope definition
-<pre>
-          int *p = (int []){2, 4};
-</pre>
- initializes p to point to the first element of an array of two ints, the first having the value two and the
- second, four. The expressions in this compound literal are required to be constant. The unnamed object
- has static storage duration.
-<p><!--para 9 -->
- EXAMPLE 2       In contrast, in
-<pre>
-          void f(void)
-          {
-                int *p;
-                /*...*/
-                p = (int [2]){*p};
-                /*...*/
-          }
-</pre>
- p is assigned the address of the first element of an array of two ints, the first having the value previously
- pointed to by p and the second, zero. The expressions in this compound literal need not be constant. The
- unnamed object has automatic storage duration.
-<p><!--para 10 -->
- EXAMPLE 3 Initializers with designations can be combined with compound literals. Structure objects
- created using compound literals can be passed to functions without depending on member order:
-<pre>
-          drawline((struct point){.x=1, .y=1},
-                (struct point){.x=3, .y=4});
-</pre>
- Or, if drawline instead expected pointers to struct point:
-<!--page 105 -->
-<pre>
-          drawline(&amp;(struct point){.x=1, .y=1},
-                &amp;(struct point){.x=3, .y=4});
-</pre>
-<p><!--para 11 -->
- EXAMPLE 4        A read-only compound literal can be specified through constructions like:
-<pre>
-          (const float []){1e0, 1e1, 1e2, 1e3, 1e4, 1e5, 1e6}
-</pre>
-<p><!--para 12 -->
- EXAMPLE 5        The following three expressions have different meanings:
-<pre>
-          "/tmp/fileXXXXXX"
-          (char []){"/tmp/fileXXXXXX"}
-          (const char []){"/tmp/fileXXXXXX"}
-</pre>
- The first always has static storage duration and has type array of char, but need not be modifiable; the last
- two have automatic storage duration when they occur within the body of a function, and the first of these
- two is modifiable.
-<p><!--para 13 -->
- EXAMPLE 6 Like string literals, const-qualified compound literals can be placed into read-only memory
- and can even be shared. For example,
-<pre>
-          (const char []){"abc"} == "abc"
-</pre>
- might yield 1 if the literals' storage is shared.
-<p><!--para 14 -->
- EXAMPLE 7 Since compound literals are unnamed, a single compound literal cannot specify a circularly
- linked object. For example, there is no way to write a self-referential compound literal that could be used
- as the function argument in place of the named object endless_zeros below:
-<pre>
-          struct int_list { int car; struct int_list *cdr; };
-          struct int_list endless_zeros = {0, &amp;endless_zeros};
-          eval(endless_zeros);
-</pre>
-<p><!--para 15 -->
- EXAMPLE 8        Each compound literal creates only a single object in a given scope:
-<pre>
-          struct s { int i; };
-          int f (void)
-          {
-                struct s *p = 0, *q;
-                int j = 0;
-          again:
-                    q = p, p = &amp;((struct s){ j++ });
-                    if (j &lt; 2) goto again;
-                    return p == q &amp;&amp; q-&gt;i == 1;
-          }
-</pre>
- The function f() always returns the value 1.
-<p><!--para 16 -->
- Note that if an iteration statement were used instead of an explicit goto and a labeled statement, the
- lifetime of the unnamed object would be the body of the loop only, and on entry next time around p would
- have an indeterminate value, which would result in undefined behavior.
-<p><b> Forward references</b>: type names (<a href="#6.7.7">6.7.7</a>), initialization (<a href="#6.7.9">6.7.9</a>).
-<!--page 106 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note99" href="#note99">99)</a> Note that this differs from a cast expression. For example, a cast specifies a conversion to scalar types
- or void only, and the result of a cast expression is not an lvalue.
-</small>
-<p><small><a name="note100" href="#note100">100)</a> For example, subobjects without explicit initializers are initialized to zero.
-</small>
-<p><small><a name="note101" href="#note101">101)</a> This allows implementations to share storage for string literals and constant compound literals with
- the same or overlapping representations.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.3" href="#6.5.3">6.5.3 Unary operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          unary-expression:
-                 postfix-expression
-                 ++ unary-expression
-                 -- unary-expression
-                 unary-operator cast-expression
-                 sizeof unary-expression
-                 sizeof ( type-name )
-                 alignof ( type-name )
-          unary-operator: one of
-                 &amp; * + - ~             !
-</pre>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.3.1" href="#6.5.3.1">6.5.3.1 Prefix increment and decrement operators</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- The operand of the prefix increment or decrement operator shall have atomic, qualified,
- or unqualified real or pointer type, and shall be a modifiable lvalue.
-<p><b>Semantics</b>
-<p><!--para 2 -->
- The value of the operand of the prefix ++ operator is incremented. The result is the new
- value of the operand after incrementation. The expression ++E is equivalent to (E+=1).
- See the discussions of additive operators and compound assignment for information on
- constraints, types, side effects, and conversions and the effects of operations on pointers.
-<p><!--para 3 -->
- The prefix -- operator is analogous to the prefix ++ operator, except that the value of the
- operand is decremented.
-<p><b> Forward references</b>: additive operators (<a href="#6.5.6">6.5.6</a>), compound assignment (<a href="#6.5.16.2">6.5.16.2</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.3.2" href="#6.5.3.2">6.5.3.2 Address and indirection operators</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- The operand of the unary &amp; operator shall be either a function designator, the result of a
- [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is
- not declared with the register storage-class specifier.
-<p><!--para 2 -->
- The operand of the unary * operator shall have pointer type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The unary &amp; operator yields the address of its operand. If the operand has type ''type'',
- the result has type ''pointer to type''. If the operand is the result of a unary * operator,
- neither that operator nor the &amp; operator is evaluated and the result is as if both were
- omitted, except that the constraints on the operators still apply and the result is not an
-<!--page 107 -->
- lvalue. Similarly, if the operand is the result of a [] operator, neither the &amp; operator nor
- the unary * that is implied by the [] is evaluated and the result is as if the &amp; operator
- were removed and the [] operator were changed to a + operator. Otherwise, the result is
- a pointer to the object or function designated by its operand.
-<p><!--para 4 -->
- The unary * operator denotes indirection. If the operand points to a function, the result is
- a function designator; if it points to an object, the result is an lvalue designating the
- object. If the operand has type ''pointer to type'', the result has type ''type''. If an
- invalid value has been assigned to the pointer, the behavior of the unary * operator is
- undefined.<sup><a href="#note102"><b>102)</b></a></sup>
-<p><b> Forward references</b>: storage-class specifiers (<a href="#6.7.1">6.7.1</a>), structure and union specifiers
- (<a href="#6.7.2.1">6.7.2.1</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note102" href="#note102">102)</a> Thus, &amp;*E is equivalent to E (even if E is a null pointer), and &amp;(E1[E2]) to ((E1)+(E2)). It is
- always true that if E is a function designator or an lvalue that is a valid operand of the unary &amp;
- operator, *&amp;E is a function designator or an lvalue equal to E. If *P is an lvalue and T is the name of
- an object pointer type, *(T)P is an lvalue that has a type compatible with that to which T points.
- Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an
- address inappropriately aligned for the type of object pointed to, and the address of an object after the
- end of its lifetime.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.3.3" href="#6.5.3.3">6.5.3.3 Unary arithmetic operators</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- The operand of the unary + or - operator shall have arithmetic type; of the ~ operator,
- integer type; of the ! operator, scalar type.
-<p><b>Semantics</b>
-<p><!--para 2 -->
- The result of the unary + operator is the value of its (promoted) operand. The integer
- promotions are performed on the operand, and the result has the promoted type.
-<p><!--para 3 -->
- The result of the unary - operator is the negative of its (promoted) operand. The integer
- promotions are performed on the operand, and the result has the promoted type.
-<p><!--para 4 -->
- The result of the ~ operator is the bitwise complement of its (promoted) operand (that is,
- each bit in the result is set if and only if the corresponding bit in the converted operand is
- not set). The integer promotions are performed on the operand, and the result has the
- promoted type. If the promoted type is an unsigned type, the expression ~E is equivalent
- to the maximum value representable in that type minus E.
-<p><!--para 5 -->
- The result of the logical negation operator ! is 0 if the value of its operand compares
- unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int.
- The expression !E is equivalent to (0==E).
-<!--page 108 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.3.4" href="#6.5.3.4">6.5.3.4 The sizeof and alignof operators</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- The sizeof operator shall not be applied to an expression that has function type or an
- incomplete type, to the parenthesized name of such a type, or to an expression that
- designates a bit-field member. The alignof operator shall not be applied to a function
- type or an incomplete type.
-<p><b>Semantics</b>
-<p><!--para 2 -->
- The sizeof operator yields the size (in bytes) of its operand, which may be an
- expression or the parenthesized name of a type. The size is determined from the type of
- the operand. The result is an integer. If the type of the operand is a variable length array
- type, the operand is evaluated; otherwise, the operand is not evaluated and the result is an
- integer constant.
-<p><!--para 3 -->
- The alignof operator yields the alignment requirement of its operand type. The result
- is an integer constant. When applied to an array type, the result is the alignment
- requirement of the element type.
-<p><!--para 4 -->
- When sizeof is applied to an operand that has type char, unsigned char, or
- signed char, (or a qualified version thereof) the result is 1. When applied to an
- operand that has array type, the result is the total number of bytes in the array.<sup><a href="#note103"><b>103)</b></a></sup> When
- applied to an operand that has structure or union type, the result is the total number of
- bytes in such an object, including internal and trailing padding.
-<p><!--para 5 -->
- The value of the result of both operators is implementation-defined, and its type (an
- unsigned integer type) is size_t, defined in <a href="#7.19">&lt;stddef.h&gt;</a> (and other headers).
-<p><!--para 6 -->
- EXAMPLE 1 A principal use of the sizeof operator is in communication with routines such as storage
- allocators and I/O systems. A storage-allocation function might accept a size (in bytes) of an object to
- allocate and return a pointer to void. For example:
-<pre>
-         extern void *alloc(size_t);
-         double *dp = alloc(sizeof *dp);
-</pre>
- The implementation of the alloc function should ensure that its return value is aligned suitably for
- conversion to a pointer to double.
-<p><!--para 7 -->
- EXAMPLE 2      Another use of the sizeof operator is to compute the number of elements in an array:
-<pre>
-         sizeof array / sizeof array[0]
-</pre>
-<p><!--para 8 -->
- EXAMPLE 3      In this example, the size of a variable length array is computed and returned from a
- function:
-<pre>
-         #include <a href="#7.19">&lt;stddef.h&gt;</a>
-</pre>
-<!--page 109 -->
-<pre>
-          size_t fsize3(int n)
-          {
-                char b[n+3];                  // variable length array
-                return sizeof b;              // execution time sizeof
-          }
-          int main()
-          {
-                size_t size;
-                size = fsize3(10); // fsize3 returns 13
-                return 0;
-          }
-</pre>
-<p><b> Forward references</b>: common definitions <a href="#7.19">&lt;stddef.h&gt;</a> (<a href="#7.19">7.19</a>), declarations (<a href="#6.7">6.7</a>),
- structure and union specifiers (<a href="#6.7.2.1">6.7.2.1</a>), type names (<a href="#6.7.7">6.7.7</a>), array declarators (<a href="#6.7.6.2">6.7.6.2</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note103" href="#note103">103)</a> When applied to a parameter declared to have array or function type, the sizeof operator yields the
- size of the adjusted (pointer) type (see <a href="#6.9.1">6.9.1</a>).
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.4" href="#6.5.4">6.5.4 Cast operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          cast-expression:
-                 unary-expression
-                 ( type-name ) cast-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Unless the type name specifies a void type, the type name shall specify atomic, qualified,
- or unqualified scalar type, and the operand shall have scalar type.
-<p><!--para 3 -->
- Conversions that involve pointers, other than where permitted by the constraints of
- <a href="#6.5.16.1">6.5.16.1</a>, shall be specified by means of an explicit cast.
-<p><!--para 4 -->
- A pointer type shall not be converted to any floating type. A floating type shall not be
- converted to any pointer type.
-<p><b>Semantics</b>
-<p><!--para 5 -->
- Preceding an expression by a parenthesized type name converts the value of the
- expression to the named type. This construction is called a cast.<sup><a href="#note104"><b>104)</b></a></sup> A cast that specifies
- no conversion has no effect on the type or value of an expression.
-<p><!--para 6 -->
- If the value of the expression is represented with greater precision or range than required
- by the type named by the cast (<a href="#6.3.1.8">6.3.1.8</a>), then the cast specifies a conversion even if the
- type of the expression is the same as the named type and removes any extra range and
- precision.
-<p><b> Forward references</b>: equality operators (<a href="#6.5.9">6.5.9</a>), function declarators (including
- prototypes) (<a href="#6.7.6.3">6.7.6.3</a>), simple assignment (<a href="#6.5.16.1">6.5.16.1</a>), type names (<a href="#6.7.7">6.7.7</a>).
-<!--page 110 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note104" href="#note104">104)</a> A cast does not yield an lvalue. Thus, a cast to a qualified type has the same effect as a cast to the
- unqualified version of the type.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.5" href="#6.5.5">6.5.5 Multiplicative operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          multiplicative-expression:
-                  cast-expression
-                  multiplicative-expression * cast-expression
-                  multiplicative-expression / cast-expression
-                  multiplicative-expression % cast-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each of the operands shall have arithmetic type. The operands of the % operator shall
- have integer type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The usual arithmetic conversions are performed on the operands.
-<p><!--para 4 -->
- The result of the binary * operator is the product of the operands.
-<p><!--para 5 -->
- The result of the / operator is the quotient from the division of the first operand by the
- second; the result of the % operator is the remainder. In both operations, if the value of
- the second operand is zero, the behavior is undefined.
-<p><!--para 6 -->
- When integers are divided, the result of the / operator is the algebraic quotient with any
- fractional part discarded.<sup><a href="#note105"><b>105)</b></a></sup> If the quotient a/b is representable, the expression
- (a/b)*b + a%b shall equal a; otherwise, the behavior of both a/b and a%b is
- undefined.
-
-<p><b>Footnotes</b>
-<p><small><a name="note105" href="#note105">105)</a> This is often called ''truncation toward zero''.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.6" href="#6.5.6">6.5.6 Additive operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          additive-expression:
-                 multiplicative-expression
-                 additive-expression + multiplicative-expression
-                 additive-expression - multiplicative-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- For addition, either both operands shall have arithmetic type, or one operand shall be a
- pointer to a complete object type and the other shall have integer type. (Incrementing is
- equivalent to adding 1.)
-<p><!--para 3 -->
- For subtraction, one of the following shall hold:
-<!--page 111 -->
-<ul>
-<li>  both operands have arithmetic type;
-<li>  both operands are pointers to qualified or unqualified versions of compatible complete
- object types; or
-<li>  the left operand is a pointer to a complete object type and the right operand has
- integer type.
-</ul>
- (Decrementing is equivalent to subtracting 1.)
-<p><b>Semantics</b>
-<p><!--para 4 -->
- If both operands have arithmetic type, the usual arithmetic conversions are performed on
- them.
-<p><!--para 5 -->
- The result of the binary + operator is the sum of the operands.
-<p><!--para 6 -->
- The result of the binary - operator is the difference resulting from the subtraction of the
- second operand from the first.
-<p><!--para 7 -->
- For the purposes of these operators, a pointer to an object that is not an element of an
- array behaves the same as a pointer to the first element of an array of length one with the
- type of the object as its element type.
-<p><!--para 8 -->
- When an expression that has integer type is added to or subtracted from a pointer, the
- result has the type of the pointer operand. If the pointer operand points to an element of
- an array object, and the array is large enough, the result points to an element offset from
- the original element such that the difference of the subscripts of the resulting and original
- array elements equals the integer expression. In other words, if the expression P points to
- the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and
- (P)-N (where N has the value n) point to, respectively, the i+n-th and i-n-th elements of
- the array object, provided they exist. Moreover, if the expression P points to the last
- element of an array object, the expression (P)+1 points one past the last element of the
- array object, and if the expression Q points one past the last element of an array object,
- the expression (Q)-1 points to the last element of the array object. If both the pointer
- operand and the result point to elements of the same array object, or one past the last
- element of the array object, the evaluation shall not produce an overflow; otherwise, the
- behavior is undefined. If the result points one past the last element of the array object, it
- shall not be used as the operand of a unary * operator that is evaluated.
-<p><!--para 9 -->
- When two pointers are subtracted, both shall point to elements of the same array object,
- or one past the last element of the array object; the result is the difference of the
- subscripts of the two array elements. The size of the result is implementation-defined,
- and its type (a signed integer type) is ptrdiff_t defined in the <a href="#7.19">&lt;stddef.h&gt;</a> header.
- If the result is not representable in an object of that type, the behavior is undefined. In
- other words, if the expressions P and Q point to, respectively, the i-th and j-th elements of
- an array object, the expression (P)-(Q) has the value i-j provided the value fits in an
-<!--page 112 -->
- object of type ptrdiff_t. Moreover, if the expression P points either to an element of
- an array object or one past the last element of an array object, and the expression Q points
- to the last element of the same array object, the expression ((Q)+1)-(P) has the same
- value as ((Q)-(P))+1 and as -((P)-((Q)+1)), and has the value zero if the
- expression P points one past the last element of the array object, even though the
- expression (Q)+1 does not point to an element of the array object.<sup><a href="#note106"><b>106)</b></a></sup>
-<p><!--para 10 -->
- EXAMPLE        Pointer arithmetic is well defined with pointers to variable length array types.
-<pre>
-          {
-                   int n = 4, m = 3;
-                   int a[n][m];
-                   int (*p)[m] = a;            //   p == &amp;a[0]
-                   p += 1;                     //   p == &amp;a[1]
-                   (*p)[2] = 99;               //   a[1][2] == 99
-                   n = p - a;                  //   n == 1
-          }
-</pre>
-<p><!--para 11 -->
- If array a in the above example were declared to be an array of known constant size, and pointer p were
- declared to be a pointer to an array of the same known constant size (pointing to a), the results would be
- the same.
-<p><b> Forward references</b>: array declarators (<a href="#6.7.6.2">6.7.6.2</a>), common definitions <a href="#7.19">&lt;stddef.h&gt;</a>
- (<a href="#7.19">7.19</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note106" href="#note106">106)</a> Another way to approach pointer arithmetic is first to convert the pointer(s) to character pointer(s): In
- this scheme the integer expression added to or subtracted from the converted pointer is first multiplied
- by the size of the object originally pointed to, and the resulting pointer is converted back to the
- original type. For pointer subtraction, the result of the difference between the character pointers is
- similarly divided by the size of the object originally pointed to.
- When viewed in this way, an implementation need only provide one extra byte (which may overlap
- another object in the program) just after the end of the object in order to satisfy the ''one past the last
- element'' requirements.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.7" href="#6.5.7">6.5.7 Bitwise shift operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          shift-expression:
-                  additive-expression
-                  shift-expression &lt;&lt; additive-expression
-                  shift-expression &gt;&gt; additive-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each of the operands shall have integer type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The integer promotions are performed on each of the operands. The type of the result is
- that of the promoted left operand. If the value of the right operand is negative or is
-<!--page 113 -->
- greater than or equal to the width of the promoted left operand, the behavior is undefined.
-<p><!--para 4 -->
- The result of E1 &lt;&lt; E2 is E1 left-shifted E2 bit positions; vacated bits are filled with
- zeros. If E1 has an unsigned type, the value of the result is E1 x 2E2 , reduced modulo
- one more than the maximum value representable in the result type. If E1 has a signed
- type and nonnegative value, and E1 x 2E2 is representable in the result type, then that is
- the resulting value; otherwise, the behavior is undefined.
-<p><!--para 5 -->
- The result of E1 &gt;&gt; E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type
- or if E1 has a signed type and a nonnegative value, the value of the result is the integral
- part of the quotient of E1 / 2E2 . If E1 has a signed type and a negative value, the
- resulting value is implementation-defined.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.8" href="#6.5.8">6.5.8 Relational operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          relational-expression:
-                  shift-expression
-                  relational-expression   &lt;    shift-expression
-                  relational-expression   &gt;    shift-expression
-                  relational-expression   &lt;=   shift-expression
-                  relational-expression   &gt;=   shift-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- One of the following shall hold:
-<ul>
-<li>  both operands have real type; or                                                            *
-<li>  both operands are pointers to qualified or unqualified versions of compatible object
- types.
-</ul>
-<p><b>Semantics</b>
-<p><!--para 3 -->
- If both of the operands have arithmetic type, the usual arithmetic conversions are
- performed.
-<p><!--para 4 -->
- For the purposes of these operators, a pointer to an object that is not an element of an
- array behaves the same as a pointer to the first element of an array of length one with the
- type of the object as its element type.
-<p><!--para 5 -->
- When two pointers are compared, the result depends on the relative locations in the
- address space of the objects pointed to. If two pointers to object types both point to the
- same object, or both point one past the last element of the same array object, they
- compare equal. If the objects pointed to are members of the same aggregate object,
- pointers to structure members declared later compare greater than pointers to members
- declared earlier in the structure, and pointers to array elements with larger subscript
- values compare greater than pointers to elements of the same array with lower subscript
-<!--page 114 -->
- values. All pointers to members of the same union object compare equal. If the
- expression P points to an element of an array object and the expression Q points to the
- last element of the same array object, the pointer expression Q+1 compares greater than
- P. In all other cases, the behavior is undefined.
-<p><!--para 6 -->
- Each of the operators &lt; (less than), &gt; (greater than), &lt;= (less than or equal to), and &gt;=
- (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is
- false.<sup><a href="#note107"><b>107)</b></a></sup> The result has type int.
-
-<p><b>Footnotes</b>
-<p><small><a name="note107" href="#note107">107)</a> The expression a&lt;b&lt;c is not interpreted as in ordinary mathematics. As the syntax indicates, it
- means (a&lt;b)&lt;c; in other words, ''if a is less than b, compare 1 to c; otherwise, compare 0 to c''.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.9" href="#6.5.9">6.5.9 Equality operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          equality-expression:
-                 relational-expression
-                 equality-expression == relational-expression
-                 equality-expression != relational-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- One of the following shall hold:
-<ul>
-<li>  both operands have arithmetic type;
-<li>  both operands are pointers to qualified or unqualified versions of compatible types;
-<li>  one operand is a pointer to an object type and the other is a pointer to a qualified or
- unqualified version of void; or
-<li>  one operand is a pointer and the other is a null pointer constant.
-</ul>
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The == (equal to) and != (not equal to) operators are analogous to the relational
- operators except for their lower precedence.<sup><a href="#note108"><b>108)</b></a></sup> Each of the operators yields 1 if the
- specified relation is true and 0 if it is false. The result has type int. For any pair of
- operands, exactly one of the relations is true.
-<p><!--para 4 -->
- If both of the operands have arithmetic type, the usual arithmetic conversions are
- performed. Values of complex types are equal if and only if both their real parts are equal
- and also their imaginary parts are equal. Any two values of arithmetic types from
- different type domains are equal if and only if the results of their conversions to the
- (complex) result type determined by the usual arithmetic conversions are equal.
-<!--page 115 -->
-<p><!--para 5 -->
- Otherwise, at least one operand is a pointer. If one operand is a pointer and the other is a
- null pointer constant, the null pointer constant is converted to the type of the pointer. If
- one operand is a pointer to an object type and the other is a pointer to a qualified or
- unqualified version of void, the former is converted to the type of the latter.
-<p><!--para 6 -->
- Two pointers compare equal if and only if both are null pointers, both are pointers to the
- same object (including a pointer to an object and a subobject at its beginning) or function,
- both are pointers to one past the last element of the same array object, or one is a pointer
- to one past the end of one array object and the other is a pointer to the start of a different
- array object that happens to immediately follow the first array object in the address
- space.<sup><a href="#note109"><b>109)</b></a></sup>
-<p><!--para 7 -->
- For the purposes of these operators, a pointer to an object that is not an element of an
- array behaves the same as a pointer to the first element of an array of length one with the
- type of the object as its element type.
-
-<p><b>Footnotes</b>
-<p><small><a name="note108" href="#note108">108)</a> Because of the precedences, a&lt;b == c&lt;d is 1 whenever a&lt;b and c&lt;d have the same truth-value.
-</small>
-<p><small><a name="note109" href="#note109">109)</a> Two objects may be adjacent in memory because they are adjacent elements of a larger array or
- adjacent members of a structure with no padding between them, or because the implementation chose
- to place them so, even though they are unrelated. If prior invalid pointer operations (such as accesses
- outside array bounds) produced undefined behavior, subsequent comparisons also produce undefined
- behavior.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.10" href="#6.5.10">6.5.10 Bitwise AND operator</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          AND-expression:
-                equality-expression
-                AND-expression &amp; equality-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each of the operands shall have integer type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The usual arithmetic conversions are performed on the operands.
-<p><!--para 4 -->
- The result of the binary &amp; operator is the bitwise AND of the operands (that is, each bit in
- the result is set if and only if each of the corresponding bits in the converted operands is
- set).
-<!--page 116 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.11" href="#6.5.11">6.5.11 Bitwise exclusive OR operator</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          exclusive-OR-expression:
-                  AND-expression
-                  exclusive-OR-expression ^ AND-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each of the operands shall have integer type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The usual arithmetic conversions are performed on the operands.
-<p><!--para 4 -->
- The result of the ^ operator is the bitwise exclusive OR of the operands (that is, each bit
- in the result is set if and only if exactly one of the corresponding bits in the converted
- operands is set).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.12" href="#6.5.12">6.5.12 Bitwise inclusive OR operator</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          inclusive-OR-expression:
-                  exclusive-OR-expression
-                  inclusive-OR-expression | exclusive-OR-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each of the operands shall have integer type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The usual arithmetic conversions are performed on the operands.
-<p><!--para 4 -->
- The result of the | operator is the bitwise inclusive OR of the operands (that is, each bit in
- the result is set if and only if at least one of the corresponding bits in the converted
- operands is set).
-<!--page 117 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.13" href="#6.5.13">6.5.13 Logical AND operator</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          logical-AND-expression:
-                  inclusive-OR-expression
-                  logical-AND-expression &amp;&amp; inclusive-OR-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each of the operands shall have scalar type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The &amp;&amp; operator shall yield 1 if both of its operands compare unequal to 0; otherwise, it
- yields 0. The result has type int.
-<p><!--para 4 -->
- Unlike the bitwise binary &amp; operator, the &amp;&amp; operator guarantees left-to-right evaluation;
- if the second operand is evaluated, there is a sequence point between the evaluations of
- the first and second operands. If the first operand compares equal to 0, the second
- operand is not evaluated.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.14" href="#6.5.14">6.5.14 Logical OR operator</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          logical-OR-expression:
-                  logical-AND-expression
-                  logical-OR-expression || logical-AND-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Each of the operands shall have scalar type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The || operator shall yield 1 if either of its operands compare unequal to 0; otherwise, it
- yields 0. The result has type int.
-<p><!--para 4 -->
- Unlike the bitwise | operator, the || operator guarantees left-to-right evaluation; if the
- second operand is evaluated, there is a sequence point between the evaluations of the first
- and second operands. If the first operand compares unequal to 0, the second operand is
- not evaluated.
-<!--page 118 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.15" href="#6.5.15">6.5.15 Conditional operator</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          conditional-expression:
-                 logical-OR-expression
-                 logical-OR-expression ? expression : conditional-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- The first operand shall have scalar type.
-<p><!--para 3 -->
- One of the following shall hold for the second and third operands:
-<ul>
-<li>  both operands have arithmetic type;
-<li>  both operands have the same structure or union type;
-<li>  both operands have void type;
-<li>  both operands are pointers to qualified or unqualified versions of compatible types;
-<li>  one operand is a pointer and the other is a null pointer constant; or
-<li>  one operand is a pointer to an object type and the other is a pointer to a qualified or
- unqualified version of void.
-</ul>
-<p><b>Semantics</b>
-<p><!--para 4 -->
- The first operand is evaluated; there is a sequence point between its evaluation and the
- evaluation of the second or third operand (whichever is evaluated). The second operand
- is evaluated only if the first compares unequal to 0; the third operand is evaluated only if
- the first compares equal to 0; the result is the value of the second or third operand
- (whichever is evaluated), converted to the type described below.<sup><a href="#note110"><b>110)</b></a></sup>                        *
-<p><!--para 5 -->
- If both the second and third operands have arithmetic type, the result type that would be
- determined by the usual arithmetic conversions, were they applied to those two operands,
- is the type of the result. If both the operands have structure or union type, the result has
- that type. If both operands have void type, the result has void type.
-<p><!--para 6 -->
- If both the second and third operands are pointers or one is a null pointer constant and the
- other is a pointer, the result type is a pointer to a type qualified with all the type qualifiers
- of the types referenced by both operands. Furthermore, if both operands are pointers to
- compatible types or to differently qualified versions of compatible types, the result type is
- a pointer to an appropriately qualified version of the composite type; if one operand is a
- null pointer constant, the result has the type of the other operand; otherwise, one operand
- is a pointer to void or a qualified version of void, in which case the result type is a
- pointer to an appropriately qualified version of void.
-<!--page 119 -->
-<p><!--para 7 -->
- EXAMPLE The common type that results when the second and third operands are pointers is determined
- in two independent stages. The appropriate qualifiers, for example, do not depend on whether the two
- pointers have compatible types.
-<p><!--para 8 -->
- Given the declarations
-<pre>
-           const void *c_vp;
-           void *vp;
-           const int *c_ip;
-           volatile int *v_ip;
-           int *ip;
-           const char *c_cp;
-</pre>
- the third column in the following table is the common type that is the result of a conditional expression in
- which the first two columns are the second and third operands (in either order):
-<pre>
-           c_vp    c_ip      const void *
-           v_ip    0         volatile int *
-           c_ip    v_ip      const volatile int *
-           vp      c_cp      const void *
-           ip      c_ip      const int *
-           vp      ip        void *
-</pre>
-
-<p><b>Footnotes</b>
-<p><small><a name="note110" href="#note110">110)</a> A conditional expression does not yield an lvalue.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.16" href="#6.5.16">6.5.16 Assignment operators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          assignment-expression:
-                 conditional-expression
-                 unary-expression assignment-operator assignment-expression
-          assignment-operator: one of
-                 = *= /= %= +=                       -=     &lt;&lt;=      &gt;&gt;=      &amp;=     ^=     |=
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- An assignment operator shall have a modifiable lvalue as its left operand.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- An assignment operator stores a value in the object designated by the left operand. An
- assignment expression has the value of the left operand after the assignment,<sup><a href="#note111"><b>111)</b></a></sup> but is not
- an lvalue. The type of an assignment expression is the type the left operand would have
- after lvalue conversion. The side effect of updating the stored value of the left operand is
- sequenced after the value computations of the left and right operands. The evaluations of
- the operands are unsequenced.
-<!--page 120 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note111" href="#note111">111)</a> The implementation is permitted to read the object to determine the value but is not required to, even
- when the object has volatile-qualified type.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.16.1" href="#6.5.16.1">6.5.16.1 Simple assignment</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- One of the following shall hold:<sup><a href="#note112"><b>112)</b></a></sup>
-<ul>
-<li>  the left operand has atomic, qualified, or unqualified arithmetic type, and the right has
- arithmetic type;
-<li>  the left operand has an atomic, qualified, or unqualified version of a structure or union
- type compatible with the type of the right;
-<li>  the left operand has atomic, qualified, or unqualified pointer type, and (considering
- the type the left operand would have after lvalue conversion) both operands are
- pointers to qualified or unqualified versions of compatible types, and the type pointed
- to by the left has all the qualifiers of the type pointed to by the right;
-<li>  the left operand has atomic, qualified, or unqualified pointer type, and (considering
- the type the left operand would have after lvalue conversion) one operand is a pointer
- to an object type, and the other is a pointer to a qualified or unqualified version of
- void, and the type pointed to by the left has all the qualifiers of the type pointed to
- by the right;
-<li>  the left operand is an atomic, qualified, or unqualified pointer, and the right is a null
- pointer constant; or
-<li>  the left operand has type atomic, qualified, or unqualified _Bool, and the right is a
- pointer.
-</ul>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- In simple assignment (=), the value of the right operand is converted to the type of the
- assignment expression and replaces the value stored in the object designated by the left
- operand.
-<p><!--para 3 -->
- If the value being stored in an object is read from another object that overlaps in any way
- the storage of the first object, then the overlap shall be exact and the two objects shall
- have qualified or unqualified versions of a compatible type; otherwise, the behavior is
- undefined.
-<p><!--para 4 -->
- EXAMPLE 1       In the program fragment
-<!--page 121 -->
-<pre>
-         int f(void);
-         char c;
-         /* ... */
-         if ((c = f()) == -1)
-                 /* ... */
-</pre>
- the int value returned by the function may be truncated when stored in the char, and then converted back
- to int width prior to the comparison. In an implementation in which ''plain'' char has the same range of
- values as unsigned char (and char is narrower than int), the result of the conversion cannot be
- negative, so the operands of the comparison can never compare equal. Therefore, for full portability, the
- variable c should be declared as int.
-<p><!--para 5 -->
- EXAMPLE 2       In the fragment:
-<pre>
-         char c;
-         int i;
-         long l;
-         l = (c = i);
-</pre>
- the value of i is converted to the type of the assignment expression c = i, that is, char type. The value
- of the expression enclosed in parentheses is then converted to the type of the outer assignment expression,
- that is, long int type.
-<p><!--para 6 -->
- EXAMPLE 3       Consider the fragment:
-<pre>
-         const char **cpp;
-         char *p;
-         const char c = 'A';
-         cpp = &amp;p;                  // constraint violation
-         *cpp = &amp;c;                 // valid
-         *p = 0;                    // valid
-</pre>
- The first assignment is unsafe because it would allow the following valid code to attempt to change the
- value of the const object c.
-
-<p><b>Footnotes</b>
-<p><small><a name="note112" href="#note112">112)</a> The asymmetric appearance of these constraints with respect to type qualifiers is due to the conversion
- (specified in <a href="#6.3.2.1">6.3.2.1</a>) that changes lvalues to ''the value of the expression'' and thus removes any type
- qualifiers that were applied to the type category of the expression (for example, it removes const but
- not volatile from the type int volatile * const).
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.5.16.2" href="#6.5.16.2">6.5.16.2 Compound assignment</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- For the operators += and -= only, either the left operand shall be an atomic, qualified, or
- unqualified pointer to a complete object type, and the right shall have integer type; or the
- left operand shall have atomic, qualified, or unqualified arithmetic type, and the right
- shall have arithmetic type.
-<p><!--para 2 -->
- For the other operators, the left operand shall have atomic, qualified, or unqualified
- arithmetic type, and (considering the type the left operand would have after lvalue
- conversion) each operand shall have arithmetic type consistent with those allowed by the
- corresponding binary operator.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- A compound assignment of the form E1 op = E2 is equivalent to the simple assignment
- expression E1 = E1 op (E2), except that the lvalue E1 is evaluated only once, and with
- respect to an indeterminately-sequenced function call, the operation of a compound
-<!--page 122 -->
- assignment is a single evaluation. If E1 has an atomic type, compound assignment is a
- read-modify-write operation with memory_order_seq_cst memory order
- semantics.<sup><a href="#note113"><b>113)</b></a></sup>
-
-<p><b>Footnotes</b>
-<p><small><a name="note113" href="#note113">113)</a> Where a pointer to an atomic object can be formed, this is equivalent to the following code sequence
- where T is the type of E1:
-
-<pre>
-          T tmp = E1;
-          T result;
-          do {
-                result = tmp op (E2);
-          } while (!atomic_compare_exchange_strong(&amp;E1, &amp;tmp, result));
-</pre>
-  with result being the result of the operation.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.5.17" href="#6.5.17">6.5.17 Comma operator</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          expression:
-                 assignment-expression
-                 expression , assignment-expression
-</pre>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- The left operand of a comma operator is evaluated as a void expression; there is a
- sequence point between its evaluation and that of the right operand. Then the right
- operand is evaluated; the result has its type and value.<sup><a href="#note114"><b>114)</b></a></sup>                        *
-<p><!--para 3 -->
- EXAMPLE As indicated by the syntax, the comma operator (as described in this subclause) cannot
- appear in contexts where a comma is used to separate items in a list (such as arguments to functions or lists
- of initializers). On the other hand, it can be used within a parenthesized expression or within the second
- expression of a conditional operator in such contexts. In the function call
-<pre>
-          f(a, (t=3, t+2), c)
-</pre>
- the function has three arguments, the second of which has the value 5.
-<p><b> Forward references</b>: initialization (<a href="#6.7.9">6.7.9</a>).
-<!--page 123 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note114" href="#note114">114)</a> A comma operator does not yield an lvalue.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="6.6" href="#6.6">6.6 Constant expressions</a></h3>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          constant-expression:
-                 conditional-expression
-</pre>
-<p><b>Description</b>
-<p><!--para 2 -->
- A constant expression can be evaluated during translation rather than runtime, and
- accordingly may be used in any place that a constant may be.
-<p><b>Constraints</b>
-<p><!--para 3 -->
- Constant expressions shall not contain assignment, increment, decrement, function-call,
- or comma operators, except when they are contained within a subexpression that is not
- evaluated.<sup><a href="#note115"><b>115)</b></a></sup>
-<p><!--para 4 -->
- Each constant expression shall evaluate to a constant that is in the range of representable
- values for its type.
-<p><b>Semantics</b>
-<p><!--para 5 -->
- An expression that evaluates to a constant is required in several contexts. If a floating
- expression is evaluated in the translation environment, the arithmetic precision and range
- shall be at least as great as if the expression were being evaluated in the execution
- environment.<sup><a href="#note116"><b>116)</b></a></sup>
-<p><!--para 6 -->
- An integer constant expression<sup><a href="#note117"><b>117)</b></a></sup> shall have integer type and shall only have operands
- that are integer constants, enumeration constants, character constants, sizeof
- expressions whose results are integer constants, and floating constants that are the
- immediate operands of casts. Cast operators in an integer constant expression shall only
- convert arithmetic types to integer types, except as part of an operand to the sizeof
- operator.
-<p><!--para 7 -->
- More latitude is permitted for constant expressions in initializers. Such a constant
- expression shall be, or evaluate to, one of the following:
-<ul>
-<li>  an arithmetic constant expression,
-<!--page 124 -->
-<li>  a null pointer constant,
-<li>  an address constant, or
-<li>  an address constant for a complete object type plus or minus an integer constant
- expression.
-</ul>
-<p><!--para 8 -->
- An arithmetic constant expression shall have arithmetic type and shall only have
- operands that are integer constants, floating constants, enumeration constants, character
- constants, and sizeof expressions. Cast operators in an arithmetic constant expression
- shall only convert arithmetic types to arithmetic types, except as part of an operand to a
- sizeof operator whose result is an integer constant.
-<p><!--para 9 -->
- An address constant is a null pointer, a pointer to an lvalue designating an object of static
- storage duration, or a pointer to a function designator; it shall be created explicitly using
- the unary &amp; operator or an integer constant cast to pointer type, or implicitly by the use of
- an expression of array or function type. The array-subscript [] and member-access .
- and -&gt; operators, the address &amp; and indirection * unary operators, and pointer casts may
- be used in the creation of an address constant, but the value of an object shall not be
- accessed by use of these operators.
-<p><!--para 10 -->
- An implementation may accept other forms of constant expressions.
-<p><!--para 11 -->
- The semantic rules for the evaluation of a constant expression are the same as for
- nonconstant expressions.<sup><a href="#note118"><b>118)</b></a></sup>
-<p><b> Forward references</b>: array declarators (<a href="#6.7.6.2">6.7.6.2</a>), initialization (<a href="#6.7.9">6.7.9</a>).
-<!--page 125 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note115" href="#note115">115)</a> The operand of a sizeof operator is usually not evaluated (<a href="#6.5.3.4">6.5.3.4</a>).
-</small>
-<p><small><a name="note116" href="#note116">116)</a> The use of evaluation formats as characterized by FLT_EVAL_METHOD also applies to evaluation in
- the translation environment.
-</small>
-<p><small><a name="note117" href="#note117">117)</a> An integer constant expression is required in a number of contexts such as the size of a bit-field
- member of a structure, the value of an enumeration constant, and the size of a non-variable length
- array. Further constraints that apply to the integer constant expressions used in conditional-inclusion
- preprocessing directives are discussed in <a href="#6.10.1">6.10.1</a>.
-</small>
-<p><small><a name="note118" href="#note118">118)</a> Thus, in the following initialization,
-
-<pre>
-           static int i = 2 || 1 / 0;
-</pre>
-  the expression is a valid integer constant expression with value one.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h3><a name="6.7" href="#6.7">6.7 Declarations</a></h3>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          declaration:
-                 declaration-specifiers init-declarator-list<sub>opt</sub> ;
-                 static_assert-declaration
-          declaration-specifiers:
-                 storage-class-specifier declaration-specifiers<sub>opt</sub>
-                 type-specifier declaration-specifiers<sub>opt</sub>
-                 type-qualifier declaration-specifiers<sub>opt</sub>
-                 function-specifier declaration-specifiers<sub>opt</sub>
-                 alignment-specifier declaration-specifiers<sub>opt</sub>
-          init-declarator-list:
-                  init-declarator
-                  init-declarator-list , init-declarator
-          init-declarator:
-                  declarator
-                  declarator = initializer
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- A declaration other than a static_assert declaration shall declare at least a declarator
- (other than the parameters of a function or the members of a structure or union), a tag, or
- the members of an enumeration.
-<p><!--para 3 -->
- If an identifier has no linkage, there shall be no more than one declaration of the identifier
- (in a declarator or type specifier) with the same scope and in the same name space, except
- that a typedef name can be redefined to denote the same type as it currently does and tags
- may be redeclared as specified in <a href="#6.7.2.3">6.7.2.3</a>.
-<p><!--para 4 -->
- All declarations in the same scope that refer to the same object or function shall specify
- compatible types.
-<p><b>Semantics</b>
-<p><!--para 5 -->
- A declaration specifies the interpretation and attributes of a set of identifiers. A definition
- of an identifier is a declaration for that identifier that:
-<ul>
-<li>  for an object, causes storage to be reserved for that object;
-<li>  for a function, includes the function body;<sup><a href="#note119"><b>119)</b></a></sup>
-<!--page 126 -->
-<li>  for an enumeration constant or typedef name, is the (only) declaration of the
- identifier.
-</ul>
-<p><!--para 6 -->
- The declaration specifiers consist of a sequence of specifiers that indicate the linkage,
- storage duration, and part of the type of the entities that the declarators denote. The init-
- declarator-list is a comma-separated sequence of declarators, each of which may have
- additional type information, or an initializer, or both. The declarators contain the
- identifiers (if any) being declared.
-<p><!--para 7 -->
- If an identifier for an object is declared with no linkage, the type for the object shall be
- complete by the end of its declarator, or by the end of its init-declarator if it has an
- initializer; in the case of function parameters (including in prototypes), it is the adjusted
- type (see <a href="#6.7.6.3">6.7.6.3</a>) that is required to be complete.
-<p><b> Forward references</b>: declarators (<a href="#6.7.6">6.7.6</a>), enumeration specifiers (<a href="#6.7.2.2">6.7.2.2</a>), initialization
- (<a href="#6.7.9">6.7.9</a>), type names (<a href="#6.7.7">6.7.7</a>), type qualifiers (<a href="#6.7.3">6.7.3</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note119" href="#note119">119)</a> Function definitions have a different syntax, described in <a href="#6.9.1">6.9.1</a>.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.7.1" href="#6.7.1">6.7.1 Storage-class specifiers</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          storage-class-specifier:
-                 typedef
-                 extern
-                 static
-                 _Thread_local
-                 auto
-                 register
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- At most, one storage-class specifier may be given in the declaration specifiers in a
- declaration, except that _Thread_local may appear with static or extern.<sup><a href="#note120"><b>120)</b></a></sup>
-<p><!--para 3 -->
- In the declaration of an object with block scope, if the declaration specifiers include
- _Thread_local, they shall also include either static or extern. If
- _Thread_local appears in any declaration of an object, it shall be present in every
- declaration of that object.
-<p><b>Semantics</b>
-<p><!--para 4 -->
- The typedef specifier is called a ''storage-class specifier'' for syntactic convenience
- only; it is discussed in <a href="#6.7.8">6.7.8</a>. The meanings of the various linkages and storage durations
- were discussed in <a href="#6.2.2">6.2.2</a> and <a href="#6.2.4">6.2.4</a>.
-<!--page 127 -->
-<p><!--para 5 -->
- A declaration of an identifier for an object with storage-class specifier register
- suggests that access to the object be as fast as possible. The extent to which such
- suggestions are effective is implementation-defined.<sup><a href="#note121"><b>121)</b></a></sup>
-<p><!--para 6 -->
- The declaration of an identifier for a function that has block scope shall have no explicit
- storage-class specifier other than extern.
-<p><!--para 7 -->
- If an aggregate or union object is declared with a storage-class specifier other than
- typedef, the properties resulting from the storage-class specifier, except with respect to
- linkage, also apply to the members of the object, and so on recursively for any aggregate
- or union member objects.
-<p><b> Forward references</b>: type definitions (<a href="#6.7.8">6.7.8</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note120" href="#note120">120)</a> See ''future language directions'' (<a href="#6.11.5">6.11.5</a>).
-</small>
-<p><small><a name="note121" href="#note121">121)</a> The implementation may treat any register declaration simply as an auto declaration. However,
- whether or not addressable storage is actually used, the address of any part of an object declared with
- storage-class specifier register cannot be computed, either explicitly (by use of the unary &amp;
- operator as discussed in <a href="#6.5.3.2">6.5.3.2</a>) or implicitly (by converting an array name to a pointer as discussed in
- <a href="#6.3.2.1">6.3.2.1</a>). Thus, the only operator that can be applied to an array declared with storage-class specifier
- register is sizeof.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.7.2" href="#6.7.2">6.7.2 Type specifiers</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          type-specifier:
-                 void
-                 char
-                 short
-                 int
-                 long
-                 float
-                 double
-                 signed
-                 unsigned
-                 _Bool
-                 _Complex
-                 atomic-type-specifier
-                 struct-or-union-specifier
-                 enum-specifier
-                 typedef-name
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- At least one type specifier shall be given in the declaration specifiers in each declaration,
- and in the specifier-qualifier list in each struct declaration and type name. Each list of
-<!--page 128 -->
- type specifiers shall be one of the following multisets (delimited by commas, when there
- is more than one multiset per item); the type specifiers may occur in any order, possibly
- intermixed with the other declaration specifiers.
-<ul>
-<li>  void
-<li>  char
-<li>  signed char
-<li>  unsigned char
-<li>  short, signed short, short int, or signed short int
-<li>  unsigned short, or unsigned short int
-<li>  int, signed, or signed int
-<li>  unsigned, or unsigned int
-<li>  long, signed long, long int, or signed long int
-<li>  unsigned long, or unsigned long int
-<li>  long long, signed long long, long long int, or
- signed long long int
-<li>  unsigned long long, or unsigned long long int
-<li>  float
-<li>  double
-<li>  long double
-<li>  _Bool
-<li>  float _Complex
-<li>  double _Complex
-<li>  long double _Complex
-<li>  atomic type specifier
-<li>  struct or union specifier
-<li>  enum specifier
-<li>  typedef name
-</ul>
-<p><!--para 3 -->
- The type specifier _Complex shall not be used if the implementation does not support
- complex types (see <a href="#6.10.8.3">6.10.8.3</a>).
-<!--page 129 -->
-<p><b>Semantics</b>
-<p><!--para 4 -->
- Specifiers for structures, unions, enumerations, and atomic types are discussed in <a href="#6.7.2.1">6.7.2.1</a>
- through <a href="#6.7.2.4">6.7.2.4</a>. Declarations of typedef names are discussed in <a href="#6.7.8">6.7.8</a>. The
- characteristics of the other types are discussed in <a href="#6.2.5">6.2.5</a>.
-<p><!--para 5 -->
- Each of the comma-separated multisets designates the same type, except that for bit-
- fields, it is implementation-defined whether the specifier int designates the same type as
- signed int or the same type as unsigned int.
-<p><b> Forward references</b>: atomic type specifiers (<a href="#6.7.2.4">6.7.2.4</a>), enumeration specifiers (<a href="#6.7.2.2">6.7.2.2</a>),
- structure and union specifiers (<a href="#6.7.2.1">6.7.2.1</a>), tags (<a href="#6.7.2.3">6.7.2.3</a>), type definitions (<a href="#6.7.8">6.7.8</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.7.2.1" href="#6.7.2.1">6.7.2.1 Structure and union specifiers</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          struct-or-union-specifier:
-                  struct-or-union identifier<sub>opt</sub> { struct-declaration-list }
-                  struct-or-union identifier
-          struct-or-union:
-                  struct
-                  union
-          struct-declaration-list:
-                  struct-declaration
-                  struct-declaration-list struct-declaration
-          struct-declaration:
-                  specifier-qualifier-list struct-declarator-list<sub>opt</sub> ;
-                  static_assert-declaration
-          specifier-qualifier-list:
-                 type-specifier specifier-qualifier-list<sub>opt</sub>
-                 type-qualifier specifier-qualifier-list<sub>opt</sub>
-          struct-declarator-list:
-                  struct-declarator
-                  struct-declarator-list , struct-declarator
-          struct-declarator:
-                  declarator
-                  declarator<sub>opt</sub> : constant-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- A struct-declaration that does not declare an anonymous structure or anonymous union
- shall contain a struct-declarator-list.
-<!--page 130 -->
-<p><!--para 3 -->
- A structure or union shall not contain a member with incomplete or function type (hence,
- a structure shall not contain an instance of itself, but may contain a pointer to an instance
- of itself), except that the last member of a structure with more than one named member
- may have incomplete array type; such a structure (and any union containing, possibly
- recursively, a member that is such a structure) shall not be a member of a structure or an
- element of an array.
-<p><!--para 4 -->
- The expression that specifies the width of a bit-field shall be an integer constant
- expression with a nonnegative value that does not exceed the width of an object of the
- type that would be specified were the colon and expression omitted.<sup><a href="#note122"><b>122)</b></a></sup> If the value is
- zero, the declaration shall have no declarator.
-<p><!--para 5 -->
- A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed
- int, unsigned int, or some other implementation-defined type. It is
- implementation-defined whether atomic types are permitted.
-<p><b>Semantics</b>
-<p><!--para 6 -->
- As discussed in <a href="#6.2.5">6.2.5</a>, a structure is a type consisting of a sequence of members, whose
- storage is allocated in an ordered sequence, and a union is a type consisting of a sequence
- of members whose storage overlap.
-<p><!--para 7 -->
- Structure and union specifiers have the same form. The keywords struct and union
- indicate that the type being specified is, respectively, a structure type or a union type.
-<p><!--para 8 -->
- The presence of a struct-declaration-list in a struct-or-union-specifier declares a new type,
- within a translation unit. The struct-declaration-list is a sequence of declarations for the
- members of the structure or union. If the struct-declaration-list contains no named
- members, no anonymous structures, and no anonymous unions, the behavior is undefined.
- The type is incomplete until immediately after the } that terminates the list, and complete
- thereafter.
-<p><!--para 9 -->
- A member of a structure or union may have any complete object type other than a
- variably modified type.<sup><a href="#note123"><b>123)</b></a></sup> In addition, a member may be declared to consist of a
- specified number of bits (including a sign bit, if any). Such a member is called a
- bit-field;<sup><a href="#note124"><b>124)</b></a></sup> its width is preceded by a colon.
-<p><!--para 10 -->
- A bit-field is interpreted as having a signed or unsigned integer type consisting of the
- specified number of bits.<sup><a href="#note125"><b>125)</b></a></sup> If the value 0 or 1 is stored into a nonzero-width bit-field of
-<!--page 131 -->
- type _Bool, the value of the bit-field shall compare equal to the value stored; a _Bool
- bit-field has the semantics of a _Bool.
-<p><!--para 11 -->
- An implementation may allocate any addressable storage unit large enough to hold a bit-
- field. If enough space remains, a bit-field that immediately follows another bit-field in a
- structure shall be packed into adjacent bits of the same unit. If insufficient space remains,
- whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is
- implementation-defined. The order of allocation of bit-fields within a unit (high-order to
- low-order or low-order to high-order) is implementation-defined. The alignment of the
- addressable storage unit is unspecified.
-<p><!--para 12 -->
- A bit-field declaration with no declarator, but only a colon and a width, indicates an
- unnamed bit-field.<sup><a href="#note126"><b>126)</b></a></sup> As a special case, a bit-field structure member with a width of 0
- indicates that no further bit-field is to be packed into the unit in which the previous bit-
- field, if any, was placed.
-<p><!--para 13 -->
- An unnamed member of structure type with no tag is called an anonymous structure; an
- unnamed member of union type with no tag is called an anonymous union. The members
- of an anonymous structure or union are considered to be members of the containing
- structure or union. This applies recursively if the containing structure or union is also
- anonymous.
-<p><!--para 14 -->
- Each non-bit-field member of a structure or union object is aligned in an implementation-
- defined manner appropriate to its type.
-<p><!--para 15 -->
- Within a structure object, the non-bit-field members and the units in which bit-fields
- reside have addresses that increase in the order in which they are declared. A pointer to a
- structure object, suitably converted, points to its initial member (or if that member is a
- bit-field, then to the unit in which it resides), and vice versa. There may be unnamed
- padding within a structure object, but not at its beginning.
-<p><!--para 16 -->
- The size of a union is sufficient to contain the largest of its members. The value of at
- most one of the members can be stored in a union object at any time. A pointer to a
- union object, suitably converted, points to each of its members (or if a member is a bit-
- field, then to the unit in which it resides), and vice versa.
-<p><!--para 17 -->
- There may be unnamed padding at the end of a structure or union.
-<p><!--para 18 -->
- As a special case, the last element of a structure with more than one named member may
- have an incomplete array type; this is called a flexible array member. In most situations,
-<!--page 132 -->
- the flexible array member is ignored. In particular, the size of the structure is as if the
- flexible array member were omitted except that it may have more trailing padding than
- the omission would imply. However, when a . (or -&gt;) operator has a left operand that is
- (a pointer to) a structure with a flexible array member and the right operand names that
- member, it behaves as if that member were replaced with the longest array (with the same
- element type) that would not make the structure larger than the object being accessed; the
- offset of the array shall remain that of the flexible array member, even if this would differ
- from that of the replacement array. If this array would have no elements, it behaves as if
- it had one element but the behavior is undefined if any attempt is made to access that
- element or to generate a pointer one past it.
-<p><!--para 19 -->
- EXAMPLE 1       The following illustrates anonymous structures and unions:
-<pre>
-          struct v {
-                union {      // anonymous union
-                       struct { int i, j; };    // anonymous structure
-                       struct { long k, l; } w;
-                };
-                int m;
-          } v1;
-          v1.i = 2;   // valid
-          v1.k = 3;   // invalid: inner structure is not anonymous
-          v1.w.k = 5; // valid
-</pre>
-<p><!--para 20 -->
- EXAMPLE 2       After the declaration:
-<pre>
-          struct s { int n; double d[]; };
-</pre>
- the structure struct s has a flexible array member d. A typical way to use this is:
-<pre>
-          int m = /* some value */;
-          struct s *p = malloc(sizeof (struct s) + sizeof (double [m]));
-</pre>
- and assuming that the call to malloc succeeds, the object pointed to by p behaves, for most purposes, as if
- p had been declared as:
-<pre>
-          struct { int n; double d[m]; } *p;
-</pre>
- (there are circumstances in which this equivalence is broken; in particular, the offsets of member d might
- not be the same).
-<p><!--para 21 -->
- Following the above declaration:
-<pre>
-          struct s t1 = { 0 };                         //   valid
-          struct s t2 = { 1, { <a href="#4.2">4.2</a> }};                 //   invalid
-          t1.n = 4;                                    //   valid
-          t1.d[0] = <a href="#4.2">4.2</a>;                               //   might be undefined behavior
-</pre>
- The initialization of t2 is invalid (and violates a constraint) because struct s is treated as if it did not
- contain member d. The assignment to t1.d[0] is probably undefined behavior, but it is possible that
-<pre>
-          sizeof (struct s) &gt;= offsetof(struct s, d) + sizeof (double)
-</pre>
- in which case the assignment would be legitimate. Nevertheless, it cannot appear in strictly conforming
- code.
-<!--page 133 -->
-<p><!--para 22 -->
- After the further declaration:
-<pre>
-          struct ss { int n; };
-</pre>
- the expressions:
-<pre>
-          sizeof (struct s) &gt;= sizeof (struct ss)
-          sizeof (struct s) &gt;= offsetof(struct s, d)
-</pre>
- are always equal to 1.
-<p><!--para 23 -->
- If sizeof (double) is 8, then after the following code is executed:
-<pre>
-          struct s *s1;
-          struct s *s2;
-          s1 = malloc(sizeof (struct s) + 64);
-          s2 = malloc(sizeof (struct s) + 46);
-</pre>
- and assuming that the calls to malloc succeed, the objects pointed to by s1 and s2 behave, for most
- purposes, as if the identifiers had been declared as:
-<pre>
-          struct { int n; double d[8]; } *s1;
-          struct { int n; double d[5]; } *s2;
-</pre>
-<p><!--para 24 -->
- Following the further successful assignments:
-<pre>
-          s1 = malloc(sizeof (struct s) + 10);
-          s2 = malloc(sizeof (struct s) + 6);
-</pre>
- they then behave as if the declarations were:
-<pre>
-          struct { int n; double d[1]; } *s1, *s2;
-</pre>
- and:
-<pre>
-          double *dp;
-          dp = &amp;(s1-&gt;d[0]);          //   valid
-          *dp = 42;                  //   valid
-          dp = &amp;(s2-&gt;d[0]);          //   valid
-          *dp = 42;                  //   undefined behavior
-</pre>
-<p><!--para 25 -->
- The assignment:
-<pre>
-          *s1 = *s2;
-</pre>
- only copies the member n; if any of the array elements are within the first sizeof (struct s) bytes
- of the structure, they might be copied or simply overwritten with indeterminate values.
-<p><b> Forward references</b>: declarators (<a href="#6.7.6">6.7.6</a>), tags (<a href="#6.7.2.3">6.7.2.3</a>).
-<!--page 134 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note122" href="#note122">122)</a> While the number of bits in a _Bool object is at least CHAR_BIT, the width (number of sign and
- value bits) of a _Bool may be just 1 bit.
-</small>
-<p><small><a name="note123" href="#note123">123)</a> A structure or union cannot contain a member with a variably modified type because member names
- are not ordinary identifiers as defined in <a href="#6.2.3">6.2.3</a>.
-</small>
-<p><small><a name="note124" href="#note124">124)</a> The unary &amp; (address-of) operator cannot be applied to a bit-field object; thus, there are no pointers to
- or arrays of bit-field objects.
-</small>
-<p><small><a name="note125" href="#note125">125)</a> As specified in <a href="#6.7.2">6.7.2</a> above, if the actual type specifier used is int or a typedef-name defined as int,
- then it is implementation-defined whether the bit-field is signed or unsigned.
-</small>
-<p><small><a name="note126" href="#note126">126)</a> An unnamed bit-field structure member is useful for padding to conform to externally imposed
- layouts.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.7.2.2" href="#6.7.2.2">6.7.2.2 Enumeration specifiers</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          enum-specifier:
-                enum identifier<sub>opt</sub> { enumerator-list }
-                enum identifier<sub>opt</sub> { enumerator-list , }
-                enum identifier
-          enumerator-list:
-                enumerator
-                enumerator-list , enumerator
-          enumerator:
-                enumeration-constant
-                enumeration-constant = constant-expression
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- The expression that defines the value of an enumeration constant shall be an integer
- constant expression that has a value representable as an int.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- The identifiers in an enumerator list are declared as constants that have type int and
- may appear wherever such are permitted.<sup><a href="#note127"><b>127)</b></a></sup> An enumerator with = defines its
- enumeration constant as the value of the constant expression. If the first enumerator has
- no =, the value of its enumeration constant is 0. Each subsequent enumerator with no =
- defines its enumeration constant as the value of the constant expression obtained by
- adding 1 to the value of the previous enumeration constant. (The use of enumerators with
- = may produce enumeration constants with values that duplicate other values in the same
- enumeration.) The enumerators of an enumeration are also known as its members.
-<p><!--para 4 -->
- Each enumerated type shall be compatible with char, a signed integer type, or an
- unsigned integer type. The choice of type is implementation-defined,<sup><a href="#note128"><b>128)</b></a></sup> but shall be
- capable of representing the values of all the members of the enumeration. The
- enumerated type is incomplete until immediately after the } that terminates the list of
- enumerator declarations, and complete thereafter.
-<!--page 135 -->
-<p><!--para 5 -->
- EXAMPLE       The following fragment:
-<pre>
-          enum hue { chartreuse, burgundy, claret=20, winedark };
-          enum hue col, *cp;
-          col = claret;
-          cp = &amp;col;
-          if (*cp != burgundy)
-                /* ... */
-</pre>
- makes hue the tag of an enumeration, and then declares col as an object that has that type and cp as a
- pointer to an object that has that type. The enumerated values are in the set { 0, 1, 20, 21 }.
-<p><b> Forward references</b>: tags (<a href="#6.7.2.3">6.7.2.3</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note127" href="#note127">127)</a> Thus, the identifiers of enumeration constants declared in the same scope shall all be distinct from
- each other and from other identifiers declared in ordinary declarators.
-</small>
-<p><small><a name="note128" href="#note128">128)</a> An implementation may delay the choice of which integer type until all enumeration constants have
- been seen.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.7.2.3" href="#6.7.2.3">6.7.2.3 Tags</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- A specific type shall have its content defined at most once.
-<p><!--para 2 -->
- Where two declarations that use the same tag declare the same type, they shall both use
- the same choice of struct, union, or enum.
-<p><!--para 3 -->
- A type specifier of the form
-<pre>
-         enum identifier
-</pre>
- without an enumerator list shall only appear after the type it specifies is complete.
-<p><b>Semantics</b>
-<p><!--para 4 -->
- All declarations of structure, union, or enumerated types that have the same scope and
- use the same tag declare the same type. Irrespective of whether there is a tag or what
- other declarations of the type are in the same translation unit, the type is incomplete<sup><a href="#note129"><b>129)</b></a></sup>
- until immediately after the closing brace of the list defining the content, and complete
- thereafter.
-<p><!--para 5 -->
- Two declarations of structure, union, or enumerated types which are in different scopes or
- use different tags declare distinct types. Each declaration of a structure, union, or
- enumerated type which does not include a tag declares a distinct type.
-<p><!--para 6 -->
- A type specifier of the form
-<!--page 136 -->
-<pre>
-          struct-or-union identifier<sub>opt</sub> { struct-declaration-list }
-</pre>
- or
-<pre>
-          enum identifier<sub>opt</sub> { enumerator-list }
-</pre>
- or
-<pre>
-          enum identifier<sub>opt</sub> { enumerator-list , }
-</pre>
- declares a structure, union, or enumerated type. The list defines the structure content,
- union content, or enumeration content. If an identifier is provided,<sup><a href="#note130"><b>130)</b></a></sup> the type specifier
- also declares the identifier to be the tag of that type.
-<p><!--para 7 -->
- A declaration of the form
-<pre>
-          struct-or-union identifier ;
-</pre>
- specifies a structure or union type and declares the identifier as a tag of that type.<sup><a href="#note131"><b>131)</b></a></sup>
-<p><!--para 8 -->
- If a type specifier of the form
-<pre>
-          struct-or-union identifier
-</pre>
- occurs other than as part of one of the above forms, and no other declaration of the
- identifier as a tag is visible, then it declares an incomplete structure or union type, and
- declares the identifier as the tag of that type.<sup><a href="#note131"><b>131)</b></a></sup>
-<p><!--para 9 -->
- If a type specifier of the form
-<pre>
-          struct-or-union identifier
-</pre>
- or
-<pre>
-          enum identifier
-</pre>
- occurs other than as part of one of the above forms, and a declaration of the identifier as a
- tag is visible, then it specifies the same type as that other declaration, and does not
- redeclare the tag.
-<p><!--para 10 -->
- EXAMPLE 1       This mechanism allows declaration of a self-referential structure.
-<pre>
-          struct tnode {
-                int count;
-                struct tnode *left, *right;
-          };
-</pre>
- specifies a structure that contains an integer and two pointers to objects of the same type. Once this
- declaration has been given, the declaration
-<!--page 137 -->
-<pre>
-          struct tnode s, *sp;
-</pre>
- declares s to be an object of the given type and sp to be a pointer to an object of the given type. With
- these declarations, the expression sp-&gt;left refers to the left struct tnode pointer of the object to
- which sp points; the expression s.right-&gt;count designates the count member of the right struct
- tnode pointed to from s.
-<p><!--para 11 -->
- The following alternative formulation uses the typedef mechanism:
-<pre>
-          typedef struct tnode TNODE;
-          struct tnode {
-                int count;
-                TNODE *left, *right;
-          };
-          TNODE s, *sp;
-</pre>
-<p><!--para 12 -->
- EXAMPLE 2 To illustrate the use of prior declaration of a tag to specify a pair of mutually referential
- structures, the declarations
-<pre>
-          struct s1 { struct s2 *s2p; /* ... */ }; // D1
-          struct s2 { struct s1 *s1p; /* ... */ }; // D2
-</pre>
- specify a pair of structures that contain pointers to each other. Note, however, that if s2 were already
- declared as a tag in an enclosing scope, the declaration D1 would refer to it, not to the tag s2 declared in
- D2. To eliminate this context sensitivity, the declaration
-<pre>
-          struct s2;
-</pre>
- may be inserted ahead of D1. This declares a new tag s2 in the inner scope; the declaration D2 then
- completes the specification of the new type.
-<p><b> Forward references</b>: declarators (<a href="#6.7.6">6.7.6</a>), type definitions (<a href="#6.7.8">6.7.8</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note129" href="#note129">129)</a> An incomplete type may only by used when the size of an object of that type is not needed. It is not
- needed, for example, when a typedef name is declared to be a specifier for a structure or union, or
- when a pointer to or a function returning a structure or union is being declared. (See incomplete types
- in <a href="#6.2.5">6.2.5</a>.) The specification has to be complete before such a function is called or defined.
-</small>
-<p><small><a name="note130" href="#note130">130)</a> If there is no identifier, the type can, within the translation unit, only be referred to by the declaration
- of which it is a part. Of course, when the declaration is of a typedef name, subsequent declarations
- can make use of that typedef name to declare objects having the specified structure, union, or
- enumerated type.
-</small>
-<p><small><a name="note131" href="#note131">131)</a> A similar construction with enum does not exist.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.7.2.4" href="#6.7.2.4">6.7.2.4 Atomic type specifiers</a></h5>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          atomic-type-specifier:
-                 _Atomic ( type-name )
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Atomic type specifiers shall not be used if the implementation does not support atomic
- types (see <a href="#6.10.8.3">6.10.8.3</a>).
-<p><!--para 3 -->
- The type name in an atomic type specifier shall not refer to an array type, a function type,
- an atomic type, or a qualified type.
-<p><b>Semantics</b>
-<p><!--para 4 -->
- The properties associated with atomic types are meaningful only for expressions that are
- lvalues. If the _Atomic keyword is immediately followed by a left parenthesis, it is
- interpreted as a type specifier (with a type name), not as a type qualifier.
-<!--page 138 -->
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.7.3" href="#6.7.3">6.7.3 Type qualifiers</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          type-qualifier:
-                 const
-                 restrict
-                 volatile
-                 _Atomic
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Types other than pointer types whose referenced type is an object type shall not be
- restrict-qualified.
-<p><!--para 3 -->
- The type modified by the _Atomic qualifier shall not be an array type or a function
- type.
-<p><b>Semantics</b>
-<p><!--para 4 -->
- The properties associated with qualified types are meaningful only for expressions that
- are lvalues.<sup><a href="#note132"><b>132)</b></a></sup>
-<p><!--para 5 -->
- If the same qualifier appears more than once in the same specifier-qualifier-list, either
- directly or via one or more typedefs, the behavior is the same as if it appeared only
- once. If other qualifiers appear along with the _Atomic qualifier in a specifier-qualifier-
- list, the resulting type is the so-qualified atomic type.
-<p><!--para 6 -->
- If an attempt is made to modify an object defined with a const-qualified type through use
- of an lvalue with non-const-qualified type, the behavior is undefined. If an attempt is
- made to refer to an object defined with a volatile-qualified type through use of an lvalue
- with non-volatile-qualified type, the behavior is undefined.<sup><a href="#note133"><b>133)</b></a></sup>
-<p><!--para 7 -->
- An object that has volatile-qualified type may be modified in ways unknown to the
- implementation or have other unknown side effects. Therefore any expression referring
- to such an object shall be evaluated strictly according to the rules of the abstract machine,
- as described in <a href="#5.1.2.3">5.1.2.3</a>. Furthermore, at every sequence point the value last stored in the
- object shall agree with that prescribed by the abstract machine, except as modified by the
-<!--page 139 -->
- unknown factors mentioned previously.<sup><a href="#note134"><b>134)</b></a></sup> What constitutes an access to an object that
- has volatile-qualified type is implementation-defined.
-<p><!--para 8 -->
- An object that is accessed through a restrict-qualified pointer has a special association
- with that pointer. This association, defined in <a href="#6.7.3.1">6.7.3.1</a> below, requires that all accesses to
- that object use, directly or indirectly, the value of that particular pointer.<sup><a href="#note135"><b>135)</b></a></sup> The intended
- use of the restrict qualifier (like the register storage class) is to promote
- optimization, and deleting all instances of the qualifier from all preprocessing translation
- units composing a conforming program does not change its meaning (i.e., observable
- behavior).
-<p><!--para 9 -->
- If the specification of an array type includes any type qualifiers, the element type is so-
- qualified, not the array type. If the specification of a function type includes any type
- qualifiers, the behavior is undefined.<sup><a href="#note136"><b>136)</b></a></sup>
-<p><!--para 10 -->
- For two qualified types to be compatible, both shall have the identically qualified version
- of a compatible type; the order of type qualifiers within a list of specifiers or qualifiers
- does not affect the specified type.
-<p><!--para 11 -->
- EXAMPLE 1      An object declared
-<pre>
-          extern const volatile int real_time_clock;
-</pre>
- may be modifiable by hardware, but cannot be assigned to, incremented, or decremented.
-<p><!--para 12 -->
- EXAMPLE 2 The following declarations and expressions illustrate the behavior when type qualifiers
- modify an aggregate type:
-<pre>
-          const struct s { int mem; } cs = { 1 };
-          struct s ncs; // the object ncs is modifiable
-          typedef int A[2][3];
-          const A a = {{4, 5, 6}, {7, 8, 9}}; // array of array of const int
-          int *pi;
-          const int *pci;
-          ncs = cs;            //    valid
-          cs = ncs;            //    violates modifiable lvalue constraint for =
-          pi = &amp;ncs.mem;       //    valid
-          pi = &amp;cs.mem;        //    violates type constraints for =
-          pci = &amp;cs.mem;       //    valid
-          pi = a[0];           //    invalid: a[0] has type ''const int *''
-</pre>
-<!--page 140 -->
-<p><!--para 13 -->
- EXAMPLE 3       The declaration
-<pre>
-          _Atomic volatile int *p;
-</pre>
- specifies that p has the type ''pointer to volatile atomic int'', a pointer to a volatile-qualified atomic type.
-
-<p><b>Footnotes</b>
-<p><small><a name="note132" href="#note132">132)</a> The implementation may place a const object that is not volatile in a read-only region of
- storage. Moreover, the implementation need not allocate storage for such an object if its address is
- never used.
-</small>
-<p><small><a name="note133" href="#note133">133)</a> This applies to those objects that behave as if they were defined with qualified types, even if they are
- never actually defined as objects in the program (such as an object at a memory-mapped input/output
- address).
-</small>
-<p><small><a name="note134" href="#note134">134)</a> A volatile declaration may be used to describe an object corresponding to a memory-mapped
- input/output port or an object accessed by an asynchronously interrupting function. Actions on
- objects so declared shall not be ''optimized out'' by an implementation or reordered except as
- permitted by the rules for evaluating expressions.
-</small>
-<p><small><a name="note135" href="#note135">135)</a> For example, a statement that assigns a value returned by malloc to a single pointer establishes this
- association between the allocated object and the pointer.
-</small>
-<p><small><a name="note136" href="#note136">136)</a> Both of these can occur through the use of typedefs.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.7.3.1" href="#6.7.3.1">6.7.3.1 Formal definition of restrict</a></h5>
-<p><!--para 1 -->
- Let D be a declaration of an ordinary identifier that provides a means of designating an
- object P as a restrict-qualified pointer to type T.
-<p><!--para 2 -->
- If D appears inside a block and does not have storage class extern, let B denote the
- block. If D appears in the list of parameter declarations of a function definition, let B
- denote the associated block. Otherwise, let B denote the block of main (or the block of
- whatever function is called at program startup in a freestanding environment).
-<p><!--para 3 -->
- In what follows, a pointer expression E is said to be based on object P if (at some
- sequence point in the execution of B prior to the evaluation of E) modifying P to point to
- a copy of the array object into which it formerly pointed would change the value of E.<sup><a href="#note137"><b>137)</b></a></sup>
- Note that ''based'' is defined only for expressions with pointer types.
-<p><!--para 4 -->
- During each execution of B, let L be any lvalue that has &amp;L based on P. If L is used to
- access the value of the object X that it designates, and X is also modified (by any means),
- then the following requirements apply: T shall not be const-qualified. Every other lvalue
- used to access the value of X shall also have its address based on P. Every access that
- modifies X shall be considered also to modify P, for the purposes of this subclause. If P
- is assigned the value of a pointer expression E that is based on another restricted pointer
- object P2, associated with block B2, then either the execution of B2 shall begin before
- the execution of B, or the execution of B2 shall end prior to the assignment. If these
- requirements are not met, then the behavior is undefined.
-<p><!--para 5 -->
- Here an execution of B means that portion of the execution of the program that would
- correspond to the lifetime of an object with scalar type and automatic storage duration
- associated with B.
-<p><!--para 6 -->
- A translator is free to ignore any or all aliasing implications of uses of restrict.
-<p><!--para 7 -->
- EXAMPLE 1       The file scope declarations
-<pre>
-          int * restrict a;
-          int * restrict b;
-          extern int c[];
-</pre>
- assert that if an object is accessed using one of a, b, or c, and that object is modified anywhere in the
- program, then it is never accessed using either of the other two.
-<!--page 141 -->
-<p><!--para 8 -->
- EXAMPLE 2       The function parameter declarations in the following example
-<pre>
-         void f(int n, int * restrict p, int * restrict q)
-         {
-               while (n-- &gt; 0)
-                     *p++ = *q++;
-         }
-</pre>
- assert that, during each execution of the function, if an object is accessed through one of the pointer
- parameters, then it is not also accessed through the other.
-<p><!--para 9 -->
- The benefit of the restrict qualifiers is that they enable a translator to make an effective dependence
- analysis of function f without examining any of the calls of f in the program. The cost is that the
- programmer has to examine all of those calls to ensure that none give undefined behavior. For example, the
- second call of f in g has undefined behavior because each of d[1] through d[49] is accessed through
- both p and q.
-<pre>
-          void g(void)
-          {
-                extern int d[100];
-                f(50, d + 50, d); // valid
-                f(50, d + 1, d); // undefined behavior
-          }
-</pre>
-<p><!--para 10 -->
- EXAMPLE 3       The function parameter declarations
-<pre>
-         void h(int n, int * restrict p, int * restrict q, int * restrict r)
-         {
-               int i;
-               for (i = 0; i &lt; n; i++)
-                      p[i] = q[i] + r[i];
-         }
-</pre>
- illustrate how an unmodified object can be aliased through two restricted pointers. In particular, if a and b
- are disjoint arrays, a call of the form h(100, a, b, b) has defined behavior, because array b is not
- modified within function h.
-<p><!--para 11 -->
- EXAMPLE 4 The rule limiting assignments between restricted pointers does not distinguish between a
- function call and an equivalent nested block. With one exception, only ''outer-to-inner'' assignments
- between restricted pointers declared in nested blocks have defined behavior.
-<!--page 142 -->
-<pre>
-         {
-                  int * restrict p1;
-                  int * restrict q1;
-                  p1 = q1; // undefined behavior
-                  {
-                        int * restrict p2 = p1; // valid
-                        int * restrict q2 = q1; // valid
-                        p1 = q2;                // undefined behavior
-                        p2 = q2;                // undefined behavior
-                  }
-         }
-</pre>
-<p><!--para 12 -->
- The one exception allows the value of a restricted pointer to be carried out of the block in which it (or, more
- precisely, the ordinary identifier used to designate it) is declared when that block finishes execution. For
- example, this permits new_vector to return a vector.
-<pre>
-          typedef struct { int n; float * restrict v; } vector;
-          vector new_vector(int n)
-          {
-                vector t;
-                t.n = n;
-                t.v = malloc(n * sizeof (float));
-                return t;
-          }
-</pre>
-
-<p><b>Footnotes</b>
-<p><small><a name="note137" href="#note137">137)</a> In other words, E depends on the value of P itself rather than on the value of an object referenced
- indirectly through P. For example, if identifier p has type (int **restrict), then the pointer
- expressions p and p+1 are based on the restricted pointer object designated by p, but the pointer
- expressions *p and p[1] are not.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.7.4" href="#6.7.4">6.7.4 Function specifiers</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          function-specifier:
-                 inline
-                 _Noreturn
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- Function specifiers shall be used only in the declaration of an identifier for a function.
-<p><!--para 3 -->
- An inline definition of a function with external linkage shall not contain a definition of a
- modifiable object with static or thread storage duration, and shall not contain a reference
- to an identifier with internal linkage.
-<p><!--para 4 -->
- In a hosted environment, no function specifier(s) shall appear in a declaration of main.
-<p><b>Semantics</b>
-<p><!--para 5 -->
- A function specifier may appear more than once; the behavior is the same as if it
- appeared only once.
-<p><!--para 6 -->
- A function declared with an inline function specifier is an inline function. Making a *
- function an inline function suggests that calls to the function be as fast as possible.<sup><a href="#note138"><b>138)</b></a></sup>
- The extent to which such suggestions are effective is implementation-defined.<sup><a href="#note139"><b>139)</b></a></sup>
-<!--page 143 -->
-<p><!--para 7 -->
- Any function with internal linkage can be an inline function. For a function with external
- linkage, the following restrictions apply: If a function is declared with an inline
- function specifier, then it shall also be defined in the same translation unit. If all of the
- file scope declarations for a function in a translation unit include the inline function
- specifier without extern, then the definition in that translation unit is an inline
- definition. An inline definition does not provide an external definition for the function,
- and does not forbid an external definition in another translation unit. An inline definition
- provides an alternative to an external definition, which a translator may use to implement
- any call to the function in the same translation unit. It is unspecified whether a call to the
- function uses the inline definition or the external definition.<sup><a href="#note140"><b>140)</b></a></sup>
-<p><!--para 8 -->
- A function declared with a _Noreturn function specifier shall not return to its caller.
-<p><b>Recommended practice</b>
-<p><!--para 9 -->
- The implementation should produce a diagnostic message for a function declared with a
- _Noreturn function specifier that appears to be capable of returning to its caller.
-<p><!--para 10 -->
- EXAMPLE 1 The declaration of an inline function with external linkage can result in either an external
- definition, or a definition available for use only within the translation unit. A file scope declaration with
- extern creates an external definition. The following example shows an entire translation unit.
-<pre>
-          inline double fahr(double t)
-          {
-                return (9.0 * t) / 5.0 + 32.0;
-          }
-          inline double cels(double t)
-          {
-                return (5.0 * (t - 32.0)) / 9.0;
-          }
-          extern double fahr(double);                  // creates an external definition
-          double convert(int is_fahr, double temp)
-          {
-                /* A translator may perform inline substitutions */
-                return is_fahr ? cels(temp) : fahr(temp);
-          }
-</pre>
-<p><!--para 11 -->
- Note that the definition of fahr is an external definition because fahr is also declared with extern, but
- the definition of cels is an inline definition. Because cels has external linkage and is referenced, an
- external definition has to appear in another translation unit (see <a href="#6.9">6.9</a>); the inline definition and the external
- definition are distinct and either may be used for the call.
-<p><!--para 12 -->
- EXAMPLE 2
-<!--page 144 -->
-<pre>
-          _Noreturn void f () {
-                abort(); // ok
-          }
-          _Noreturn void g (int i) { // causes undefined behavior if i &lt;= 0
-                if (i &gt; 0) abort();
-          }
-</pre>
-<p><b> Forward references</b>: function definitions (<a href="#6.9.1">6.9.1</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note138" href="#note138">138)</a> By using, for example, an alternative to the usual function call mechanism, such as ''inline
- substitution''. Inline substitution is not textual substitution, nor does it create a new function.
- Therefore, for example, the expansion of a macro used within the body of the function uses the
- definition it had at the point the function body appears, and not where the function is called; and
- identifiers refer to the declarations in scope where the body occurs. Likewise, the function has a
- single address, regardless of the number of inline definitions that occur in addition to the external
- definition.
-</small>
-<p><small><a name="note139" href="#note139">139)</a> For example, an implementation might never perform inline substitution, or might only perform inline
- substitutions to calls in the scope of an inline declaration.
-</small>
-<p><small><a name="note140" href="#note140">140)</a> Since an inline definition is distinct from the corresponding external definition and from any other
- corresponding inline definitions in other translation units, all corresponding objects with static storage
- duration are also distinct in each of the definitions.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.7.5" href="#6.7.5">6.7.5 Alignment specifier</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          alignment-specifier:
-                _Alignas ( type-name )
-                _Alignas ( constant-expression )
-</pre>
-<p><b>Constraints</b>
-<p><!--para 2 -->
- An alignment attribute shall not be specified in a declaration of a typedef, or a bit-field, or
- a function, or a parameter, or an object declared with the register storage-class
- specifier.
-<p><!--para 3 -->
- The constant expression shall be an integer constant expression. It shall evaluate to a
- valid fundamental alignment, or to a valid extended alignment supported by the
- implementation in the context in which it appears, or to zero.
-<p><!--para 4 -->
- The combined effect of all alignment attributes in a declaration shall not specify an
- alignment that is less strict than the alignment that would otherwise be required for the
- type of the object or member being declared.
-<p><b>Semantics</b>
-<p><!--para 5 -->
- The first form is equivalent to _Alignas(alignof(type-name)).
-<p><!--para 6 -->
- The alignment requirement of the declared object or member is taken to be the specified
- alignment. An alignment specification of zero has no effect.<sup><a href="#note141"><b>141)</b></a></sup> When multiple
- alignment specifiers occur in a declaration, the effective alignment requirement is the
- strictest specified alignment.
-<p><!--para 7 -->
- If the definition of an object has an alignment specifier, any other declaration of that
- object shall either specify equivalent alignment or have no alignment specifier. If the
- definition of an object does not have an alignment specifier, any other declaration of that
- object shall also have no alignment specifier. If declarations of an object in different
- translation units have different alignment specifiers, the behavior is undefined.
-<!--page 145 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note141" href="#note141">141)</a> An alignment specification of zero also does not affect other alignment specifications in the same
- declaration.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.7.6" href="#6.7.6">6.7.6 Declarators</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-          declarator:
-                 pointer<sub>opt</sub> direct-declarator
-          direct-declarator:
-                  identifier
-                  ( declarator )
-                  direct-declarator [ type-qualifier-list<sub>opt</sub> assignment-expression<sub>opt</sub> ]
-                  direct-declarator [ static type-qualifier-list<sub>opt</sub> assignment-expression ]
-                  direct-declarator [ type-qualifier-list static assignment-expression ]
-                  direct-declarator [ type-qualifier-list<sub>opt</sub> * ]
-                  direct-declarator ( parameter-type-list )
-                  direct-declarator ( identifier-list<sub>opt</sub> )
-          pointer:
-                 * type-qualifier-list<sub>opt</sub>
-                 * type-qualifier-list<sub>opt</sub> pointer
-          type-qualifier-list:
-                 type-qualifier
-                 type-qualifier-list type-qualifier
-          parameter-type-list:
-                parameter-list
-                parameter-list , ...
-          parameter-list:
-                parameter-declaration
-                parameter-list , parameter-declaration
-          parameter-declaration:
-                declaration-specifiers declarator
-                declaration-specifiers abstract-declarator<sub>opt</sub>
-          identifier-list:
-                 identifier
-                 identifier-list , identifier
-</pre>
-<p><b>Semantics</b>
-<p><!--para 2 -->
- Each declarator declares one identifier, and asserts that when an operand of the same
- form as the declarator appears in an expression, it designates a function or object with the
- scope, storage duration, and type indicated by the declaration specifiers.
-<p><!--para 3 -->
- A full declarator is a declarator that is not part of another declarator. The end of a full
- declarator is a sequence point. If, in the nested sequence of declarators in a full
-<!--page 146 -->
- declarator, there is a declarator specifying a variable length array type, the type specified
- by the full declarator is said to be variably modified. Furthermore, any type derived by
- declarator type derivation from a variably modified type is itself variably modified.
-<p><!--para 4 -->
- In the following subclauses, consider a declaration
-<pre>
-         T D1
-</pre>
- where T contains the declaration specifiers that specify a type T (such as int) and D1 is
- a declarator that contains an identifier ident. The type specified for the identifier ident in
- the various forms of declarator is described inductively using this notation.
-<p><!--para 5 -->
- If, in the declaration ''T D1'', D1 has the form
-<pre>
-         identifier
-</pre>
- then the type specified for ident is T .
-<p><!--para 6 -->
- If, in the declaration ''T D1'', D1 has the form
-<pre>
-         ( D )
-</pre>
- then ident has the type specified by the declaration ''T D''. Thus, a declarator in
- parentheses is identical to the unparenthesized declarator, but the binding of complicated
- declarators may be altered by parentheses.
-<p><b>Implementation limits</b>
-<p><!--para 7 -->
- As discussed in <a href="#5.2.4.1">5.2.4.1</a>, an implementation may limit the number of pointer, array, and
- function declarators that modify an arithmetic, structure, union, or void type, either
- directly or via one or more typedefs.
-<p><b> Forward references</b>: array declarators (<a href="#6.7.6.2">6.7.6.2</a>), type definitions (<a href="#6.7.8">6.7.8</a>).
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.7.6.1" href="#6.7.6.1">6.7.6.1 Pointer declarators</a></h5>
-<p><b>Semantics</b>
-<p><!--para 1 -->
- If, in the declaration ''T D1'', D1 has the form
-<pre>
-         * type-qualifier-list<sub>opt</sub> D
-</pre>
- and the type specified for ident in the declaration ''T D'' is ''derived-declarator-type-list
- T '', then the type specified for ident is ''derived-declarator-type-list type-qualifier-list
- pointer to T ''. For each type qualifier in the list, ident is a so-qualified pointer.
-<p><!--para 2 -->
- For two pointer types to be compatible, both shall be identically qualified and both shall
- be pointers to compatible types.
-<p><!--para 3 -->
- EXAMPLE The following pair of declarations demonstrates the difference between a ''variable pointer
- to a constant value'' and a ''constant pointer to a variable value''.
-<!--page 147 -->
-<pre>
-          const int *ptr_to_constant;
-          int *const constant_ptr;
-</pre>
- The contents of any object pointed to by ptr_to_constant shall not be modified through that pointer,
- but ptr_to_constant itself may be changed to point to another object. Similarly, the contents of the
- int pointed to by constant_ptr may be modified, but constant_ptr itself shall always point to the
- same location.
-<p><!--para 4 -->
- The declaration of the constant pointer constant_ptr may be clarified by including a definition for the
- type ''pointer to int''.
-<pre>
-          typedef int *int_ptr;
-          const int_ptr constant_ptr;
-</pre>
- declares constant_ptr as an object that has type ''const-qualified pointer to int''.
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.7.6.2" href="#6.7.6.2">6.7.6.2 Array declarators</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- In addition to optional type qualifiers and the keyword static, the [ and ] may delimit
- an expression or *. If they delimit an expression (which specifies the size of an array), the
- expression shall have an integer type. If the expression is a constant expression, it shall
- have a value greater than zero. The element type shall not be an incomplete or function
- type. The optional type qualifiers and the keyword static shall appear only in a
- declaration of a function parameter with an array type, and then only in the outermost
- array type derivation.
-<p><!--para 2 -->
- If an identifier is declared as having a variably modified type, it shall be an ordinary
- identifier (as defined in <a href="#6.2.3">6.2.3</a>), have no linkage, and have either block scope or function
- prototype scope. If an identifier is declared to be an object with static or thread storage
- duration, it shall not have a variable length array type.
-<p><b>Semantics</b>
-<p><!--para 3 -->
- If, in the declaration ''T D1'', D1 has one of the forms:
-<pre>
-          D[ type-qualifier-list<sub>opt</sub> assignment-expression<sub>opt</sub> ]
-          D[ static type-qualifier-list<sub>opt</sub> assignment-expression ]
-          D[ type-qualifier-list static assignment-expression ]
-          D[ type-qualifier-list<sub>opt</sub> * ]
-</pre>
- and the type specified for ident in the declaration ''T D'' is ''derived-declarator-type-list
- T '', then the type specified for ident is ''derived-declarator-type-list array of T ''.<sup><a href="#note142"><b>142)</b></a></sup>
- (See <a href="#6.7.6.3">6.7.6.3</a> for the meaning of the optional type qualifiers and the keyword static.)
-<p><!--para 4 -->
- If the size is not present, the array type is an incomplete type. If the size is * instead of
- being an expression, the array type is a variable length array type of unspecified size,
- which can only be used in declarations or type names with function prototype scope;<sup><a href="#note143"><b>143)</b></a></sup>
-<!--page 148 -->
- such arrays are nonetheless complete types. If the size is an integer constant expression
- and the element type has a known constant size, the array type is not a variable length
- array type; otherwise, the array type is a variable length array type. (Variable length
- arrays are a conditional feature that implementations need not support; see <a href="#6.10.8.3">6.10.8.3</a>.)
-<p><!--para 5 -->
- If the size is an expression that is not an integer constant expression: if it occurs in a
- declaration at function prototype scope, it is treated as if it were replaced by *; otherwise,
- each time it is evaluated it shall have a value greater than zero. The size of each instance
- of a variable length array type does not change during its lifetime. Where a size
- expression is part of the operand of a sizeof operator and changing the value of the
- size expression would not affect the result of the operator, it is unspecified whether or not
- the size expression is evaluated.
-<p><!--para 6 -->
- For two array types to be compatible, both shall have compatible element types, and if
- both size specifiers are present, and are integer constant expressions, then both size
- specifiers shall have the same constant value. If the two array types are used in a context
- which requires them to be compatible, it is undefined behavior if the two size specifiers
- evaluate to unequal values.
-<p><!--para 7 -->
- EXAMPLE 1
-<pre>
-          float fa[11], *afp[17];
-</pre>
- declares an array of float numbers and an array of pointers to float numbers.
-<p><!--para 8 -->
- EXAMPLE 2       Note the distinction between the declarations
-<pre>
-          extern int *x;
-          extern int y[];
-</pre>
- The first declares x to be a pointer to int; the second declares y to be an array of int of unspecified size
- (an incomplete type), the storage for which is defined elsewhere.
-<p><!--para 9 -->
- EXAMPLE 3       The following declarations demonstrate the compatibility rules for variably modified types.
-<pre>
-          extern int n;
-          extern int m;
-          void fcompat(void)
-          {
-                int a[n][6][m];
-                int (*p)[4][n+1];
-                int c[n][n][6][m];
-                int (*r)[n][n][n+1];
-                p = a;       // invalid: not compatible because 4 != 6
-                r = c;       // compatible, but defined behavior only if
-                             // n == 6 and m == n+1
-          }
-</pre>
-<!--page 149 -->
-<p><!--para 10 -->
- EXAMPLE 4 All declarations of variably modified (VM) types have to be at either block scope or
- function prototype scope. Array objects declared with the _Thread_local, static, or extern
- storage-class specifier cannot have a variable length array (VLA) type. However, an object declared with
- the static storage-class specifier can have a VM type (that is, a pointer to a VLA type). Finally, all
- identifiers declared with a VM type have to be ordinary identifiers and cannot, therefore, be members of
- structures or unions.
-<pre>
-         extern int n;
-         int A[n];                                           // invalid: file scope VLA
-         extern int (*p2)[n];                                // invalid: file scope VM
-         int B[100];                                         // valid: file scope but not VM
-         void fvla(int m, int C[m][m]);                      // valid: VLA with prototype scope
-         void fvla(int m, int C[m][m])                       // valid: adjusted to auto pointer to VLA
-         {
-               typedef int VLA[m][m];                        // valid: block scope typedef VLA
-                  struct tag {
-                        int (*y)[n];                         // invalid: y not ordinary identifier
-                        int z[n];                            // invalid: z not ordinary identifier
-                  };
-                  int D[m];                                  //   valid: auto VLA
-                  static int E[m];                           //   invalid: static block scope VLA
-                  extern int F[m];                           //   invalid: F has linkage and is VLA
-                  int (*s)[m];                               //   valid: auto pointer to VLA
-                  extern int (*r)[m];                        //   invalid: r has linkage and points to VLA
-                  static int (*q)[m] = &amp;B;                   //   valid: q is a static block pointer to VLA
-         }
-</pre>
-<p><b> Forward references</b>:          function declarators (<a href="#6.7.6.3">6.7.6.3</a>), function definitions (<a href="#6.9.1">6.9.1</a>),
- initialization (<a href="#6.7.9">6.7.9</a>).
-
-<p><b>Footnotes</b>
-<p><small><a name="note142" href="#note142">142)</a> When several ''array of'' specifications are adjacent, a multidimensional array is declared.
-</small>
-<p><small><a name="note143" href="#note143">143)</a> Thus, * can be used only in function declarations that are not definitions (see <a href="#6.7.6.3">6.7.6.3</a>).
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h5><a name="6.7.6.3" href="#6.7.6.3">6.7.6.3 Function declarators (including prototypes)</a></h5>
-<p><b>Constraints</b>
-<p><!--para 1 -->
- A function declarator shall not specify a return type that is a function type or an array
- type.
-<p><!--para 2 -->
- The only storage-class specifier that shall occur in a parameter declaration is register.
-<p><!--para 3 -->
- An identifier list in a function declarator that is not part of a definition of that function
- shall be empty.
-<p><!--para 4 -->
- After adjustment, the parameters in a parameter type list in a function declarator that is
- part of a definition of that function shall not have incomplete type.
-<p><b>Semantics</b>
-<p><!--para 5 -->
- If, in the declaration ''T D1'', D1 has the form
-<!--page 150 -->
-<pre>
-        D( parameter-type-list )
-</pre>
- or
-<pre>
-        D( identifier-list<sub>opt</sub> )
-</pre>
- and the type specified for ident in the declaration ''T D'' is ''derived-declarator-type-list
- T '', then the type specified for ident is ''derived-declarator-type-list function returning
- T ''.
-<p><!--para 6 -->
- A parameter type list specifies the types of, and may declare identifiers for, the
- parameters of the function.
-<p><!--para 7 -->
- A declaration of a parameter as ''array of type'' shall be adjusted to ''qualified pointer to
- type'', where the type qualifiers (if any) are those specified within the [ and ] of the
- array type derivation. If the keyword static also appears within the [ and ] of the
- array type derivation, then for each call to the function, the value of the corresponding
- actual argument shall provide access to the first element of an array with at least as many
- elements as specified by the size expression.
-<p><!--para 8 -->
- A declaration of a parameter as ''function returning type'' shall be adjusted to ''pointer to
- function returning type'', as in <a href="#6.3.2.1">6.3.2.1</a>.
-<p><!--para 9 -->
- If the list terminates with an ellipsis (, ...), no information about the number or types
- of the parameters after the comma is supplied.<sup><a href="#note144"><b>144)</b></a></sup>
-<p><!--para 10 -->
- The special case of an unnamed parameter of type void as the only item in the list
- specifies that the function has no parameters.
-<p><!--para 11 -->
- If, in a parameter declaration, an identifier can be treated either as a typedef name or as a
- parameter name, it shall be taken as a typedef name.
-<p><!--para 12 -->
- If the function declarator is not part of a definition of that function, parameters may have
- incomplete type and may use the [*] notation in their sequences of declarator specifiers
- to specify variable length array types.
-<p><!--para 13 -->
- The storage-class specifier in the declaration specifiers for a parameter declaration, if
- present, is ignored unless the declared parameter is one of the members of the parameter
- type list for a function definition.
-<p><!--para 14 -->
- An identifier list declares only the identifiers of the parameters of the function. An empty
- list in a function declarator that is part of a definition of that function specifies that the
- function has no parameters. The empty list in a function declarator that is not part of a
- definition of that function specifies that no information about the number or types of the
- parameters is supplied.<sup><a href="#note145"><b>145)</b></a></sup>
-<!--page 151 -->
-<p><!--para 15 -->
- For two function types to be compatible, both shall specify compatible return types.<sup><a href="#note146"><b>146)</b></a></sup>
- Moreover, the parameter type lists, if both are present, shall agree in the number of
- parameters and in use of the ellipsis terminator; corresponding parameters shall have
- compatible types. If one type has a parameter type list and the other type is specified by a
- function declarator that is not part of a function definition and that contains an empty
- identifier list, the parameter list shall not have an ellipsis terminator and the type of each
- parameter shall be compatible with the type that results from the application of the
- default argument promotions. If one type has a parameter type list and the other type is
- specified by a function definition that contains a (possibly empty) identifier list, both shall
- agree in the number of parameters, and the type of each prototype parameter shall be
- compatible with the type that results from the application of the default argument
- promotions to the type of the corresponding identifier. (In the determination of type
- compatibility and of a composite type, each parameter declared with function or array
- type is taken as having the adjusted type and each parameter declared with qualified type
- is taken as having the unqualified version of its declared type.)
-<p><!--para 16 -->
- EXAMPLE 1       The declaration
-<pre>
-          int f(void), *fip(), (*pfi)();
-</pre>
- declares a function f with no parameters returning an int, a function fip with no parameter specification
- returning a pointer to an int, and a pointer pfi to a function with no parameter specification returning an
- int. It is especially useful to compare the last two. The binding of *fip() is *(fip()), so that the
- declaration suggests, and the same construction in an expression requires, the calling of a function fip,
- and then using indirection through the pointer result to yield an int. In the declarator (*pfi)(), the
- extra parentheses are necessary to indicate that indirection through a pointer to a function yields a function
- designator, which is then used to call the function; it returns an int.
-<p><!--para 17 -->
- If the declaration occurs outside of any function, the identifiers have file scope and external linkage. If the
- declaration occurs inside a function, the identifiers of the functions f and fip have block scope and either
- internal or external linkage (depending on what file scope declarations for these identifiers are visible), and
- the identifier of the pointer pfi has block scope and no linkage.
-<p><!--para 18 -->
- EXAMPLE 2       The declaration
-<pre>
-          int (*apfi[3])(int *x, int *y);
-</pre>
- declares an array apfi of three pointers to functions returning int. Each of these functions has two
- parameters that are pointers to int. The identifiers x and y are declared for descriptive purposes only and
- go out of scope at the end of the declaration of apfi.
-<p><!--para 19 -->
- EXAMPLE 3       The declaration
-<pre>
-          int (*fpfi(int (*)(long), int))(int, ...);
-</pre>
- declares a function fpfi that returns a pointer to a function returning an int. The function fpfi has two
- parameters: a pointer to a function returning an int (with one parameter of type long int), and an int.
- The pointer returned by fpfi points to a function that has one int parameter and accepts zero or more
-<!--page 152 -->
- additional arguments of any type.
-<p><!--para 20 -->
- EXAMPLE 4        The following prototype has a variably modified parameter.
-<pre>
-           void addscalar(int n, int m,
-                 double a[n][n*m+300], double x);
-           int main()
-           {
-                 double b[4][308];
-                 addscalar(4, 2, b, <a href="#2.17">2.17</a>);
-                 return 0;
-           }
-           void addscalar(int n, int m,
-                 double a[n][n*m+300], double x)
-           {
-                 for (int i = 0; i &lt; n; i++)
-                       for (int j = 0, k = n*m+300; j &lt; k; j++)
-                             // a is a pointer to a VLA with n*m+300 elements
-                             a[i][j] += x;
-           }
-</pre>
-<p><!--para 21 -->
- EXAMPLE 5        The following are all compatible function prototype declarators.
-<pre>
-           double    maximum(int       n,   int   m,   double   a[n][m]);
-           double    maximum(int       n,   int   m,   double   a[*][*]);
-           double    maximum(int       n,   int   m,   double   a[ ][*]);
-           double    maximum(int       n,   int   m,   double   a[ ][m]);
-</pre>
- as are:
-<pre>
-           void   f(double     (* restrict a)[5]);
-           void   f(double     a[restrict][5]);
-           void   f(double     a[restrict 3][5]);
-           void   f(double     a[restrict static 3][5]);
-</pre>
- (Note that the last declaration also specifies that the argument corresponding to a in any call to f must be a
- non-null pointer to the first of at least three arrays of 5 doubles, which the others do not.)
-<p><b> Forward references</b>: function definitions (<a href="#6.9.1">6.9.1</a>), type names (<a href="#6.7.7">6.7.7</a>).
-<!--page 153 -->
-
-<p><b>Footnotes</b>
-<p><small><a name="note144" href="#note144">144)</a> The macros defined in the <a href="#7.16">&lt;stdarg.h&gt;</a> header (<a href="#7.16">7.16</a>) may be used to access arguments that
- correspond to the ellipsis.
-</small>
-<p><small><a name="note145" href="#note145">145)</a> See ''future language directions'' (<a href="#6.11.6">6.11.6</a>).
-</small>
-<p><small><a name="note146" href="#note146">146)</a> If both function types are ''old style'', parameter types are not compared.
-</small>
-
-<p><small><a href="#Contents">Contents</a></small>
-<h4><a name="6.7.7" href="#6.7.7">6.7.7 Type names</a></h4>
-<p><b>Syntax</b>
-<p><!--para 1 -->
-<pre>
-