add new c1x standard draft (n1570), +pdf2html.sh script
authornsz <nsz@port70.net>
Sun, 24 Jul 2011 12:04:39 +0000 (14:04 +0200)
committernsz <nsz@port70.net>
Sun, 24 Jul 2011 12:04:39 +0000 (14:04 +0200)
n1570.html [new file with mode: 0644]
n1570.txt [new file with mode: 0644]
pdf2html.sh [new file with mode: 0755]

diff --git a/n1570.html b/n1570.html
new file mode 100644 (file)
index 0000000..a628c03
--- /dev/null
@@ -0,0 +1,34828 @@
+<html><head><title>N1570   April 12, 2011  ISO/IEC 9899:201x</title></head><body>
+<pre><!--page 1 -->
+N1570                      Committee Draft -- April 12, 2011          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 (N1539) 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 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   _Noreturn &lt;stdnoreturn.h&gt;</a>
+<li><a href="#7.24">  7.24   String handling &lt;string.h&gt;</a>
+<ul>
+<li><a href="#7.24.1">         7.24.1 String function conventions</a>
+<li><a href="#7.24.2">         7.24.2 Copying functions</a>
+<li><a href="#7.24.3">         7.24.3 Concatenation functions</a>
+<li><a href="#7.24.4">         7.24.4 Comparison functions</a>
+<li><a href="#7.24.5">         7.24.5 Search functions</a>
+<li><a href="#7.24.6">         7.24.6 Miscellaneous functions</a>
+</ul>
+<li><a href="#7.25">  7.25   Type-generic math &lt;tgmath.h&gt;</a>
+<li><a href="#7.26">  7.26   Threads &lt;threads.h&gt;</a>
+<ul>
+<li><a href="#7.26.1">         7.26.1 Introduction</a>
+<li><a href="#7.26.2">         7.26.2 Initialization functions</a>
+<li><a href="#7.26.3">         7.26.3 Condition variable functions</a>
+<li><a href="#7.26.4">         7.26.4 Mutex functions</a>
+<li><a href="#7.26.5">         7.26.5 Thread functions</a>
+<li><a href="#7.26.6">         7.26.6 Thread-specific storage functions</a>
+</ul>
+<li><a href="#7.27">  7.27   Date and time &lt;time.h&gt;</a>
+<ul>
+<li><a href="#7.27.1">         7.27.1 Components of time</a>
+<li><a href="#7.27.2">         7.27.2 Time manipulation functions</a>
+<li><a href="#7.27.3">         7.27.3 Time conversion functions</a>
+<!--page 8 -->
+</ul>
+<li><a href="#7.28">   7.28 Unicode utilities &lt;uchar.h&gt;</a>
+<ul>
+<li><a href="#7.28.1">        7.28.1 Restartable multibyte/wide character conversion functions</a>
+</ul>
+<li><a href="#7.29">   7.29 Extended multibyte and wide character utilities &lt;wchar.h&gt;</a>
+<ul>
+<li><a href="#7.29.1">        7.29.1 Introduction</a>
+<li><a href="#7.29.2">        7.29.2 Formatted wide character input/output functions</a>
+<li><a href="#7.29.3">        7.29.3 Wide character input/output functions</a>
+<li><a href="#7.29.4">        7.29.4 General wide string utilities</a>
+<ul>
+<li><a href="#7.29.4.1">                 7.29.4.1 Wide string numeric conversion functions</a>
+<li><a href="#7.29.4.2">                 7.29.4.2 Wide string copying functions</a>
+<li><a href="#7.29.4.3">                 7.29.4.3 Wide string concatenation functions</a>
+<li><a href="#7.29.4.4">                 7.29.4.4 Wide string comparison functions</a>
+<li><a href="#7.29.4.5">                 7.29.4.5 Wide string search functions</a>
+<li><a href="#7.29.4.6">                 7.29.4.6 Miscellaneous functions</a>
+</ul>
+<li><a href="#7.29.5">        7.29.5 Wide character time conversion functions</a>
+<li><a href="#7.29.6">        7.29.6 Extended multibyte/wide character conversion utilities</a>
+<ul>
+<li><a href="#7.29.6.1">                 7.29.6.1 Single-byte/wide character conversion functions</a>
+<li><a href="#7.29.6.2">                 7.29.6.2 Conversion state functions</a>
+<li><a href="#7.29.6.3">                 7.29.6.3 Restartable multibyte/wide character conversion functions</a>
+<li><a href="#7.29.6.4">                 7.29.6.4 Restartable multibyte/wide string conversion functions</a>
+</ul>
+</ul>
+<li><a href="#7.30">   7.30 Wide character classification and mapping utilities &lt;wctype.h&gt;</a>
+<ul>
+<li><a href="#7.30.1">        7.30.1 Introduction</a>
+<li><a href="#7.30.2">        7.30.2 Wide character classification utilities</a>
+<ul>
+<li><a href="#7.30.2.1">                 7.30.2.1 Wide character classification functions</a>
+<li><a href="#7.30.2.2">                 7.30.2.2 Extensible wide character classification functions</a>
+</ul>
+<li><a href="#7.30.3">        7.30.3 Wide character case mapping utilities</a>
+<ul>
+<li><a href="#7.30.3.1">                 7.30.3.1 Wide character case mapping functions</a>
+<li><a href="#7.30.3.2">                 7.30.3.2 Extensible wide character case mapping functions</a>
+</ul>
+</ul>
+<li><a href="#7.31">   7.31 Future library directions</a>
+<ul>
+<li><a href="#7.31.1">        7.31.1 Complex arithmetic &lt;complex.h&gt;</a>
+<li><a href="#7.31.2">        7.31.2 Character handling &lt;ctype.h&gt;</a>
+<li><a href="#7.31.3">        7.31.3 Errors &lt;errno.h&gt;</a>
+<li><a href="#7.31.4">        7.31.4 Floating-point environment &lt;fenv.h&gt;</a>
+<li><a href="#7.31.5">        7.31.5 Format conversion of integer types &lt;inttypes.h&gt;</a>
+<li><a href="#7.31.6">        7.31.6 Localization &lt;locale.h&gt;</a>
+<li><a href="#7.31.7">        7.31.7 Signal handling &lt;signal.h&gt;</a>
+<li><a href="#7.31.8">        7.31.8 Atomics &lt;stdatomic.h&gt;</a>
+<li><a href="#7.31.9">        7.31.9 Boolean type and values &lt;stdbool.h&gt;</a>
+<li><a href="#7.31.10">        7.31.10 Integer types &lt;stdint.h&gt;</a>
+<li><a href="#7.31.11">        7.31.11 Input/output &lt;stdio.h&gt;</a>
+<li><a href="#7.31.12">        7.31.12 General utilities &lt;stdlib.h&gt;</a>
+<!--page 9 -->
+<li><a href="#7.31.13">        7.31.13 String handling &lt;string.h&gt;</a>
+<li><a href="#7.31.14">        7.31.14 Date and time &lt;time.h&gt;</a>
+<li><a href="#7.31.15">        7.31.15 Threads &lt;threads.h&gt;</a>
+<li><a href="#7.31.16">        7.31.16 Extended multibyte and wide character utilities &lt;wchar.h&gt;</a>
+<li><a href="#7.31.17">        7.31.17 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 _Noreturn &lt;stdnoreturn.h&gt;</a>
+<li><a href="#B.23">  B.23 String handling &lt;string.h&gt;</a>
+<li><a href="#B.24">  B.24 Type-generic math &lt;tgmath.h&gt;</a>
+<li><a href="#B.25">  B.25 Threads &lt;threads.h&gt;</a>
+<li><a href="#B.26">  B.26 Date and time &lt;time.h&gt;</a>
+<li><a href="#B.27">  B.27 Unicode utilities &lt;uchar.h&gt;</a>
+<li><a href="#B.28">  B.28 Extended multibyte/wide character utilities &lt;wchar.h&gt;</a>
+<li><a href="#B.29">  B.29 Wide character classification and mapping utilities &lt;wctype.h&gt;</a>
+</ul>
+<li><a href="#C">Annex C (informative) Sequence points</a>
+<!--page 10 -->
+<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>
+<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>
+<!--page 11 -->
+</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>
+</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>
+<!--page 12 -->
+</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>
+<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.26">&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.28">&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.29">&lt;wchar.h&gt;</a> and <a href="#7.30">&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.25">&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.29">&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.31">7.31</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>
+ value representable by 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 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>,           <a href="#7.20">&lt;stdint.h&gt;</a>,         and
+ <a href="#7.23">&lt;stdnoreturn.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>),
+ <a href="#7.23">&lt;stdnoreturn.h&gt;</a> (<a href="#7.23">7.23</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, as is the state of the floating-point environment. The
+ value of any object modified by the handler that is neither a lock-free atomic object nor of
+ type volatile sig_atomic_t becomes indeterminate when the handler exits, as
+ does the state of the floating-point environment if it is modified by the handler and not
+ restored to its original state.
+<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
+<!--page 34 -->
+ overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only
+ produce the same result, possibly omitting the promotions.
+<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
+<!--page 35 -->
+ while the original expression would not; nor can the expression be rewritten either as
+<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>), floating-
+ point environment <a href="#7.6">&lt;fenv.h&gt;</a> (<a href="#7.6">7.6</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.26.4">7.26.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 headed by a release operation A 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 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, in another thread, 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.29">&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.29">&lt;wchar.h&gt;</a>
+ (<a href="#7.29">7.29</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 may be represented in greater range and precision than that required by the
+ new type (see <a href="#6.3.1.8">6.3.1.8</a> and <a href="#6.8.6.4">6.8.6.4</a>).
+
+<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 may be represented in greater range and precision than that required by the
+ new type (see <a href="#6.3.1.8">6.3.1.8</a> and <a href="#6.8.6.4">6.8.6.4</a>).
+
+<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 range and precision 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 _Alignof 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, the _Alignof 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, the _Alignof 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
+<!--page 73 -->
+ has type ''pointer to 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 and _Alignof operators (<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 or _Alignof operator remains
+ a function designator and violates the constraints 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
+                auto                        * if                             unsigned
+                break                         inline                         void
+                case                          int                            volatile
+                char                          long                           while
+                const                         register                       _Alignas
+                continue                      restrict                       _Alignof
+                default                       return                         _Atomic
+                do                            short                          _Bool
+                double                        signed                         _Complex
+                else                          sizeof                         _Generic
+                enum                          static                         _Imaginary
+                extern                        struct                         _Noreturn
+                float                         switch                         _Static_assert
+                for                           typedef                        _Thread_local
+                goto                          union
+</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.28">&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.28">&lt;uchar.h&gt;</a> (<a href="#7.28">7.28</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.28">&lt;uchar.h&gt;</a> (<a href="#7.28">7.28</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.24.2">7.24.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 range and
+ precision, 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><!--para 6 -->
+ A generic selection is a primary expression. Its type and value depend on the selected
+ generic association, as detailed in the following subclause.
+<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>
+<!--page 97 -->
+<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
+ 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>).
+<!--page 99 -->
+
+<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
+ 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;
+<!--page 100 -->
+<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.
+<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.
+<!--page 101 -->
+<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.
+<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:
+<!--page 102 -->
+<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>
+<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 and E has integer type, E++ is equivalent to the
+ following code sequence where T is the type of E:
+
+<pre>
+           T *addr = &amp;E;
+           T old = *addr;
+           T new;
+           do {
+                  new = old + 1;
+           } while (!atomic_compare_exchange_strong(addr, &amp;old, new));
+</pre>
+  with old being the result of the operation.
+  Special care must be taken if E has floating type; see <a href="#6.5.16.2">6.5.16.2</a>.
+</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
+<!--page 104 -->
+ value is given by the initializer list.<sup><a href="#note99"><b>99)</b></a></sup>
+<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>
+<!--page 105 -->
+ Or, if drawline instead expected pointers to struct point:
+<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
+ operand is not evaluated and 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 range or precision 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>
+<!--page 123 -->
+
+<p><b>Footnotes</b>
+<p><small><a name="note113" href="#note113">113)</a> Where a pointer to an atomic object can be formed and E1 and E2 have integer type, this is equivalent
+ to the following code sequence where T1 is the type of E1 and T2 is the type of E2:
+
+<pre>
+           T1 *addr = &amp;E1;
+           T2 val = (E2);
+           T1 old = *addr;
+           T1 new;
+           do {
+                 new = old op val;
+           } while (!atomic_compare_exchange_strong(addr, &amp;old, new));
+</pre>
+  with new being the result of the operation.
+  If E1 or E2 has floating type, then exceptional conditions or floating-point exceptions encountered
+  during discarded evaluations of new should also be discarded in order to satisfy the equivalence of E1
+  op = E2 and E1 = E1 op (E2). For example, if <a href="#F">annex F</a> is in effect, the floating types involved have
+  IEC 60559 formats, and FLT_EVAL_METHOD is 0, the equivalent code would be:
+
+<pre>
+           #include <a href="#7.6">&lt;fenv.h&gt;</a>
+           #pragma STDC FENV_ACCESS ON
+           /* ... */
+                   fenv_t fenv;
+                   T1 *addr = &amp;E1;
+                   T2 val = E2;
+                   T1 old = *addr;
+                   T1 new;
+                   feholdexcept(&amp;fenv);
+                   for (;;) {
+                         new = old op val;
+                         if (atomic_compare_exchange_strong(addr, &amp;old, new))
+                                     break;
+                         feclearexcept(FE_ALL_EXCEPT);
+                   }
+                   feupdateenv(&amp;fenv);
+</pre>
+  If FLT_EVAL_METHOD is not 0, then T2 must be a type with the range and precision to which E2 is
+  evaluated in order to satisfy the equivalence.
+</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 124 -->
+
+<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 range and precision
+ 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, _Alignof expressions, 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 or _Alignof 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 125 -->
+<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, sizeof expressions whose results are integer constants, and _Alignof
+ 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 or
+ _Alignof operator.
+<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 126 -->
+
+<p><b>Footnotes</b>
+<p><small><a name="note115" href="#note115">115)</a> The operand of a sizeof or _Alignof 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:
+<ul>
+<li>  a typedef name may be redefined to denote the same type as it currently does,
+ provided that type is not a variably modified type;
+<li>  tags may be redeclared as specified in <a href="#6.7.2.3">6.7.2.3</a>.
+</ul>
+<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 127 -->
+<li>  for an enumeration constant, is the (only) declaration of the identifier;
+<li>  for a typedef name, is the first (or 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><!--para 4 -->
+ _Thread_local shall not appear in the declaration specifiers of a function declaration.
+<!--page 128 -->
+<p><b>Semantics</b>
+<p><!--para 5 -->
+ 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>.
+<p><!--para 6 -->
+ 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 7 -->
+ The declaration of an identifier for a function that has block scope shall have no explicit
+ storage-class specifier other than extern.
+<p><!--para 8 -->
+ 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>).
+<!--page 129 -->
+
+<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 operators that can be applied to an array declared with storage-class specifier
+ register are sizeof and _Alignof.
+</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
+ 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
+<!--page 130 -->
+<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>).
+<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 -->
+<!--page 131 -->
+<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.
+<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.
+<!--page 132 -->
+<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 does not contain any
+ named members, either directly or via an anonymous structure or anonymous union, 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
+ 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
+<!--page 133 -->
+ 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 whose type specifier is a structure specifier with no tag is called an
+ anonymous structure; an unnamed member whose type specifier is a union specifier 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,
+ 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:
+<!--page 134 -->
+<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.
+<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:
+<!--page 135 -->
+<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><!--para 26 -->
+ EXAMPLE 3 Because members of anonymous structures and unions are considered to be members of the
+ containing structure or union, struct s in the following example has more than one named member and
+ thus the use of a flexible array member is valid:
+<pre>
+          struct s {
+                struct { int i; };
+                int a[];
+          };
+</pre>
+<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>).
+
+<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.
+<!--page 136 -->
+<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.
+<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.
+<!--page 137 -->
+<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
+<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>
+<!--page 138 -->
+<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
+<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>).
+<!--page 139 -->
+
+<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.
+
+<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-
+<!--page 140 -->
+ 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
+ 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>
+<!--page 141 -->
+ 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>
+<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
+<!--page 142 -->
+ 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.
+<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.
+<!--page 143 -->
+<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.
+<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>
+<!--page 144 -->
+ The extent to which such suggestions are effective is implementation-defined.<sup><a href="#note139"><b>139)</b></a></sup>
+<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
+</pre>
+<!--page 145 -->
+<pre>
+          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
+<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.
+<!--page 146 -->
+<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.
+
+<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>
+</pre>
+<!--page 147 -->
+<pre>
+          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
+ 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>).
+<!--page 148 -->
+
+<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''.
+<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.
+<!--page 149 -->
+<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>
+ 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
+<!--page 150 -->
+<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>
+<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>).
+<!--page 151 -->
+
+<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
+<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.
+<!--page 152 -->
+<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>
+<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
+<!--page 153 -->
+ 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&n