Incitsisoiec 989920112012 Programming Languages

C Ansi download

https://ebookbell.com/product/incitsisoiec-989920112012-
programming-languages-c-ansi-6766368

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Incits 5652020 Information Technology Next Generation Access Control

Ngac April 10 2020 Ansi Incits

https://ebookbell.com/product/incits-5652020-information-technology-
next-generation-access-control-ngac-april-10-2020-ansi-incits-19856798

Ieee Standard For Standard Systemc Language Reference Manual Ieee Std
16662011 1st Edition Incitsc

https://ebookbell.com/product/ieee-standard-for-standard-systemc-
language-reference-manual-ieee-std-16662011-1st-edition-
incitsc-50143562

Ataatapi Command Set 4 Acs4 R14 R14 Incits Technical Committee T13

https://ebookbell.com/product/ataatapi-command-
set-4-acs4-r14-r14-incits-technical-committee-t13-7353632

Scsi Multimedia Commands 6 Mmc6 R02g R02g William P Mcferrin

https://ebookbell.com/product/scsi-multimedia-
commands-6-mmc6-r02g-r02g-william-p-mcferrin-7353508
Scsi Primary Commands 5 Spc5 R19 R19 T10 Technical Committee

https://ebookbell.com/product/scsi-primary-
commands-5-spc5-r19-r19-t10-technical-committee-7353456

Scsi Block Commands 4 Sbc4 R15 R15 William Martin

https://ebookbell.com/product/scsi-block-
commands-4-sbc4-r15-r15-william-martin-7353472

Serial Attached Scsi 4 Sas4 R10b R10b 6777

https://ebookbell.com/product/serial-attached-
scsi-4-sas4-r10b-r10b-6777-7353478

Sas Protocol Layer 5 Spl5 R06 R06 T10 Technical Committee

https://ebookbell.com/product/sas-protocol-
layer-5-spl5-r06-r06-t10-technical-committee-7353486

Scsi Pci Express Queuing Interface Pqi R07 R07 T10 Technical Committee

https://ebookbell.com/product/scsi-pci-express-queuing-interface-
pqi-r07-r07-t10-technical-committee-7353496
 INCITS/ISO/IEC 9899-2011[2012]

Information Technology
Programming Languages
C

INCITS/ISO/IEC 9899-2011[2012]
(ISO/IEC 9899-2011, IDT)

Adopted by INCITS (InterNational Committee for Information Technology Standards) as an American National Standard.

Date of ANSI Approval: 5/23/2012

Published by American National Standards Institute,
25 West 43rd Street, New York, New York 10036

Copyright 2012 by Information Technology Industry Council

Printed in the United States of America

 Contents
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Normative references . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terms, definitions, and symbols . . . . . . . . . . . . . . . . . . . 3
4. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Conceptual models . . . . . . . . . . . . . . . . . . . . . 10
5.1.1 Translation environment . . . . . . . . . . . . . . . . 10
5.1.2 Execution environments . . . . . . . . . . . . . . . . 12
5.2 Environmental considerations . . . . . . . . . . . . . . . . . 22
5.2.1 Character sets . . . . . . . . . . . . . . . . . . . . 22
5.2.2 Character display semantics . . . . . . . . . . . . . . 24
5.2.3 Signals and interrupts . . . . . . . . . . . . . . . . . 25
5.2.4 Environmental limits . . . . . . . . . . . . . . . . . 25
6. Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.1 Scopes of identifiers . . . . . . . . . . . . . . . . . 35
6.2.2 Linkages of identifiers . . . . . . . . . . . . . . . . . 36
6.2.3 Name spaces of identifiers . . . . . . . . . . . . . . . 37
6.2.4 Storage durations of objects . . . . . . . . . . . . . . 38
6.2.5 Types . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.6 Representations of types . . . . . . . . . . . . . . . . 44
6.2.7 Compatible type and composite type . . . . . . . . . . . 47
6.2.8 Alignment of objects . . . . . . . . . . . . . . . . . 48
6.3 Conversions . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.1 Arithmetic operands . . . . . . . . . . . . . . . . . 50
6.3.2 Other operands . . . . . . . . . . . . . . . . . . . 54
6.4 Lexical elements . . . . . . . . . . . . . . . . . . . . . . 57
6.4.1 Keywords . . . . . . . . . . . . . . . . . . . . . . 58
6.4.2 Identifiers . . . . . . . . . . . . . . . . . . . . . . 59
6.4.3 Universal character names . . . . . . . . . . . . . . . 61
6.4.4 Constants . . . . . . . . . . . . . . . . . . . . . . 62
6.4.5 String literals . . . . . . . . . . . . . . . . . . . . 70
6.4.6 Punctuators . . . . . . . . . . . . . . . . . . . . . 72
6.4.7 Header names . . . . . . . . . . . . . . . . . . . . 73
6.4.8 Preprocessing numbers . . . . . . . . . . . . . . . . 74
6.4.9 Comments . . . . . . . . . . . . . . . . . . . . . 75
6.5 Expressions . . . . . . . . . . . . . . . . . . . . . . . . 76
6.5.1 Primary expressions . . . . . . . . . . . . . . . . . 78
6.5.2 Postfix operators . . . . . . . . . . . . . . . . . . . 79
6.5.3 Unary operators . . . . . . . . . . . . . . . . . . . 88
6.5.4 Cast operators . . . . . . . . . . . . . . . . . . . . 91
6.5.5 Multiplicative operators . . . . . . . . . . . . . . . . 92
6.5.6 Additive operators . . . . . . . . . . . . . . . . . . 92
6.5.7 Bitwise shift operators . . . . . . . . . . . . . . . . . 94
6.5.8 Relational operators . . . . . . . . . . . . . . . . . . 95
6.5.9 Equality operators . . . . . . . . . . . . . . . . . . 96
6.5.10 Bitwise AND operator . . . . . . . . . . . . . . . . . 97
6.5.11 Bitwise exclusive OR operator . . . . . . . . . . . . . 98
6.5.12 Bitwise inclusive OR operator . . . . . . . . . . . . . . 98
6.5.13 Logical AND operator . . . . . . . . . . . . . . . . . 99
6.5.14 Logical OR operator . . . . . . . . . . . . . . . . . 99
6.5.15 Conditional operator . . . . . . . . . . . . . . . . . 100
6.5.16 Assignment operators . . . . . . . . . . . . . . . . . 101
6.5.17 Comma operator . . . . . . . . . . . . . . . . . . . 105
6.6 Constant expressions . . . . . . . . . . . . . . . . . . . . . 106
6.7 Declarations . . . . . . . . . . . . . . . . . . . . . . . . 108
6.7.1 Storage-class specifiers . . . . . . . . . . . . . . . . 109
6.7.2 Type specifiers . . . . . . . . . . . . . . . . . . . . 111
6.7.3 Type qualifiers . . . . . . . . . . . . . . . . . . . . 121
6.7.4 Function specifiers . . . . . . . . . . . . . . . . . . 125
6.7.5 Alignment specifier . . . . . . . . . . . . . . . . . . 127
6.7.6 Declarators . . . . . . . . . . . . . . . . . . . . . 128
6.7.7 Type names . . . . . . . . . . . . . . . . . . . . . 136
6.7.8 Type definitions . . . . . . . . . . . . . . . . . . . 137
6.7.9 Initialization . . . . . . . . . . . . . . . . . . . . 139
6.7.10 Static assertions . . . . . . . . . . . . . . . . . . . 145
6.8 Statements and blocks . . . . . . . . . . . . . . . . . . . . 146
6.8.1 Labeled statements . . . . . . . . . . . . . . . . . . 146
6.8.2 Compound statement . . . . . . . . . . . . . . . . . 147
6.8.3 Expression and null statements . . . . . . . . . . . . . 147
6.8.4 Selection statements . . . . . . . . . . . . . . . . . 148
6.8.5 Iteration statements . . . . . . . . . . . . . . . . . . 150
6.8.6 Jump statements . . . . . . . . . . . . . . . . . . . 151
6.9 External definitions . . . . . . . . . . . . . . . . . . . . . 155
6.9.1 Function definitions . . . . . . . . . . . . . . . . . . 156
6.9.2 External object definitions . . . . . . . . . . . . . . . 158
6.10 Preprocessing directives . . . . . . . . . . . . . . . . . . . 160
6.10.1 Conditional inclusion . . . . . . . . . . . . . . . . . 162
6.10.2 Source file inclusion . . . . . . . . . . . . . . . . . 164
6.10.3 Macro replacement . . . . . . . . . . . . . . . . . . 166
 6.10.4 Line control . . . . . . . . . . . . . . . . . . . . . 173
6.10.5 Error directive . . . . . . . . . . . . . . . . . . . . 174
6.10.6 Pragma directive . . . . . . . . . . . . . . . . . . . 174
6.10.7 Null directive . . . . . . . . . . . . . . . . . . . . 175
6.10.8 Predefined macro names . . . . . . . . . . . . . . . . 175
6.10.9 Pragma operator . . . . . . . . . . . . . . . . . . . 178
6.11 Future language directions . . . . . . . . . . . . . . . . . . 179
6.11.1 Floating types . . . . . . . . . . . . . . . . . . . . 179
6.11.2 Linkages of identifiers . . . . . . . . . . . . . . . . . 179
6.11.3 External names . . . . . . . . . . . . . . . . . . . 179
6.11.4 Character escape sequences . . . . . . . . . . . . . . 179
6.11.5 Storage-class specifiers . . . . . . . . . . . . . . . . 179
6.11.6 Function declarators . . . . . . . . . . . . . . . . . 179
6.11.7 Function definitions . . . . . . . . . . . . . . . . . . 179
6.11.8 Pragma directives . . . . . . . . . . . . . . . . . . 179
6.11.9 Predefined macro names . . . . . . . . . . . . . . . . 179
7. Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 180
7.1.1 Definitions of terms . . . . . . . . . . . . . . . . . . 180
7.1.2 Standard headers . . . . . . . . . . . . . . . . . . . 181
7.1.3 Reserved identifiers . . . . . . . . . . . . . . . . . . 182
7.1.4 Use of library functions . . . . . . . . . . . . . . . . 183
7.2 Diagnostics <assert.h> . . . . . . . . . . . . . . . . . . 186
7.2.1 Program diagnostics . . . . . . . . . . . . . . . . . 186
7.3 Complex arithmetic <complex.h> . . . . . . . . . . . . . . 188
7.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . 188
7.3.2 Conventions . . . . . . . . . . . . . . . . . . . . . 189
7.3.3 Branch cuts . . . . . . . . . . . . . . . . . . . . . 189
7.3.4 The CX_LIMITED_RANGE pragma . . . . . . . . . . . 189
7.3.5 Trigonometric functions . . . . . . . . . . . . . . . . 190
7.3.6 Hyperbolic functions . . . . . . . . . . . . . . . . . 192
7.3.7 Exponential and logarithmic functions . . . . . . . . . . 194
7.3.8 Power and absolute-value functions . . . . . . . . . . . 195
7.3.9 Manipulation functions . . . . . . . . . . . . . . . . 196
7.4 Character handling <ctype.h> . . . . . . . . . . . . . . . . 200
7.4.1 Character classification functions . . . . . . . . . . . . 200
7.4.2 Character case mapping functions . . . . . . . . . . . . 203
7.5 Errors <errno.h> . . . . . . . . . . . . . . . . . . . . . 205
7.6 Floating-point environment <fenv.h> . . . . . . . . . . . . . 206
7.6.1 The FENV_ACCESS pragma . . . . . . . . . . . . . . 208
7.6.2 Floating-point exceptions . . . . . . . . . . . . . . . 209
7.6.3 Rounding . . . . . . . . . . . . . . . . . . . . . . 212
7.6.4 Environment . . . . . . . . . . . . . . . . . . . . 213
7.7 Characteristics of floating types <float.h> . . . . . . . . . . . 216
7.8 Format conversion of integer types <inttypes.h> . . . . . . . . 217
7.8.1 Macros for format specifiers . . . . . . . . . . . . . . 217
7.8.2 Functions for greatest-width integer types . . . . . . . . . 218
7.9 Alternative spellings <iso646.h> . . . . . . . . . . . . . . . 221
7.10 Sizes of integer types <limits.h> . . . . . . . . . . . . . . 222
7.11 Localization <locale.h> . . . . . . . . . . . . . . . . . . 223
7.11.1 Locale control . . . . . . . . . . . . . . . . . . . . 224
7.11.2 Numeric formatting convention inquiry . . . . . . . . . . 225
7.12 Mathematics <math.h> . . . . . . . . . . . . . . . . . . . 231
7.12.1 Treatment of error conditions . . . . . . . . . . . . . . 233
7.12.2 The FP_CONTRACT pragma . . . . . . . . . . . . . . 235
7.12.3 Classification macros . . . . . . . . . . . . . . . . . 235
7.12.4 Trigonometric functions . . . . . . . . . . . . . . . . 238
7.12.5 Hyperbolic functions . . . . . . . . . . . . . . . . . 240
7.12.6 Exponential and logarithmic functions . . . . . . . . . . 242
7.12.7 Power and absolute-value functions . . . . . . . . . . . 247
7.12.8 Error and gamma functions . . . . . . . . . . . . . . . 249
7.12.9 Nearest integer functions . . . . . . . . . . . . . . . . 251
7.12.10 Remainder functions . . . . . . . . . . . . . . . . . 254
7.12.11 Manipulation functions . . . . . . . . . . . . . . . . 255
7.12.12 Maximum, minimum, and positive difference functions . . . 257
7.12.13 Floating multiply-add . . . . . . . . . . . . . . . . . 258
7.12.14 Comparison macros . . . . . . . . . . . . . . . . . . 259
7.13 Nonlocal jumps <setjmp.h> . . . . . . . . . . . . . . . . 262
7.13.1 Save calling environment . . . . . . . . . . . . . . . 262
7.13.2 Restore calling environment . . . . . . . . . . . . . . 263
7.14 Signal handling <signal.h> . . . . . . . . . . . . . . . . . 265
7.14.1 Specify signal handling . . . . . . . . . . . . . . . . 266
7.14.2 Send signal . . . . . . . . . . . . . . . . . . . . . 267
7.15 Alignment <stdalign.h> . . . . . . . . . . . . . . . . . 268
7.16 Variable arguments <stdarg.h> . . . . . . . . . . . . . . . 269
7.16.1 Variable argument list access macros . . . . . . . . . . . 269
7.17 Atomics <stdatomic.h> . . . . . . . . . . . . . . . . . . 273
7.17.1 Introduction . . . . . . . . . . . . . . . . . . . . . 273
7.17.2 Initialization . . . . . . . . . . . . . . . . . . . . 274
7.17.3 Order and consistency . . . . . . . . . . . . . . . . . 275
7.17.4 Fences . . . . . . . . . . . . . . . . . . . . . . . 278
7.17.5 Lock-free property . . . . . . . . . . . . . . . . . . 279
7.17.6 Atomic integer types . . . . . . . . . . . . . . . . . 280
7.17.7 Operations on atomic types . . . . . . . . . . . . . . . 282
7.17.8 Atomic flag type and operations . . . . . . . . . . . . . 285
7.18 Boolean type and values <stdbool.h> . . . . . . . . . . . . 287
7.19 Common definitions <stddef.h> . . . . . . . . . . . . . . . 288
7.20 Integer types <stdint.h> . . . . . . . . . . . . . . . . . . 289
 7.20.1 Integer types . . . . . . . . . . . . . . . . . . . . 289
7.20.2 Limits of specified-width integer types . . . . . . . . . . 291
7.20.3 Limits of other integer types . . . . . . . . . . . . . . 293
7.20.4 Macros for integer constants . . . . . . . . . . . . . . 294
7.21 Input/output <stdio.h> . . . . . . . . . . . . . . . . . . 296
7.21.1 Introduction . . . . . . . . . . . . . . . . . . . . . 296
7.21.2 Streams . . . . . . . . . . . . . . . . . . . . . . 298
7.21.3 Files . . . . . . . . . . . . . . . . . . . . . . . . 300
7.21.4 Operations on files . . . . . . . . . . . . . . . . . . 302
7.21.5 File access functions . . . . . . . . . . . . . . . . . 304
7.21.6 Formatted input/output functions . . . . . . . . . . . . 309
7.21.7 Character input/output functions . . . . . . . . . . . . . 330
7.21.8 Direct input/output functions . . . . . . . . . . . . . . 335
7.21.9 File positioning functions . . . . . . . . . . . . . . . 336
7.21.10 Error-handling functions . . . . . . . . . . . . . . . . 338
7.22 General utilities <stdlib.h> . . . . . . . . . . . . . . . . 340
7.22.1 Numeric conversion functions . . . . . . . . . . . . . . 341
7.22.2 Pseudo-random sequence generation functions . . . . . . . 346
7.22.3 Memory management functions . . . . . . . . . . . . . 347
7.22.4 Communication with the environment . . . . . . . . . . 350
7.22.5 Searching and sorting utilities . . . . . . . . . . . . . . 354
7.22.6 Integer arithmetic functions . . . . . . . . . . . . . . 356
7.22.7 Multibyte/wide character conversion functions . . . . . . . 357
7.22.8 Multibyte/wide string conversion functions . . . . . . . . 359
7.23 _Noreturn <stdnoreturn.h> . . . . . . . . . . . . . . 361
7.24 String handling <string.h> . . . . . . . . . . . . . . . . . 362
7.24.1 String function conventions . . . . . . . . . . . . . . . 362
7.24.2 Copying functions . . . . . . . . . . . . . . . . . . 362
7.24.3 Concatenation functions . . . . . . . . . . . . . . . . 364
7.24.4 Comparison functions . . . . . . . . . . . . . . . . . 365
7.24.5 Search functions . . . . . . . . . . . . . . . . . . . 367
7.24.6 Miscellaneous functions . . . . . . . . . . . . . . . . 371
7.25 Type-generic math <tgmath.h> . . . . . . . . . . . . . . . 373
7.26 Threads <threads.h> . . . . . . . . . . . . . . . . . . . 376
7.26.1 Introduction . . . . . . . . . . . . . . . . . . . . . 376
7.26.2 Initialization functions . . . . . . . . . . . . . . . . . 378
7.26.3 Condition variable functions . . . . . . . . . . . . . . 378
7.26.4 Mutex functions . . . . . . . . . . . . . . . . . . . 380
7.26.5 Thread functions . . . . . . . . . . . . . . . . . . . 383
7.26.6 Thread-specific storage functions . . . . . . . . . . . . 386
7.27 Date and time <time.h> . . . . . . . . . . . . . . . . . . 388
7.27.1 Components of time . . . . . . . . . . . . . . . . . 388
7.27.2 Time manipulation functions . . . . . . . . . . . . . . 389
7.27.3 Time conversion functions . . . . . . . . . . . . . . . 392
7.28 Unicode utilities <uchar.h> . . . . . . . . . . . . . . . . . 398
7.28.1 Restartable multibyte/wide character conversion functions . . 398
7.29 Extended multibyte and wide character utilities <wchar.h> . . . . . 402
7.29.1 Introduction . . . . . . . . . . . . . . . . . . . . . 402
7.29.2 Formatted wide character input/output functions . . . . . . 403
7.29.3 Wide character input/output functions . . . . . . . . . . 421
7.29.4 General wide string utilities . . . . . . . . . . . . . . 426
7.29.4.1 Wide string numeric conversion functions . . . . . 426
7.29.4.2 Wide string copying functions . . . . . . . . . . 430
7.29.4.3 Wide string concatenation functions . . . . . . . 432
7.29.4.4 Wide string comparison functions . . . . . . . . 433
7.29.4.5 Wide string search functions . . . . . . . . . . 435
7.29.4.6 Miscellaneous functions . . . . . . . . . . . . 439
7.29.5 Wide character time conversion functions . . . . . . . . . 439
7.29.6 Extended multibyte/wide character conversion utilities . . . . 440
7.29.6.1 Single-byte/wide character conversion functions . . . 441
7.29.6.2 Conversion state functions . . . . . . . . . . . 441
7.29.6.3 Restartable multibyte/wide character conversion
functions . . . . . . . . . . . . . . . . . . 442
7.29.6.4 Restartable multibyte/wide string conversion
functions . . . . . . . . . . . . . . . . . . 444
7.30 Wide character classification and mapping utilities <wctype.h> . . . 447
7.30.1 Introduction . . . . . . . . . . . . . . . . . . . . . 447
7.30.2 Wide character classification utilities . . . . . . . . . . . 448
7.30.2.1 Wide character classification functions . . . . . . 448
7.30.2.2 Extensible wide character classification
functions . . . . . . . . . . . . . . . . . . 451
7.30.3 Wide character case mapping utilities . . . . . . . . . . . 453
7.30.3.1 Wide character case mapping functions . . . . . . 453
7.30.3.2 Extensible wide character case mapping
functions . . . . . . . . . . . . . . . . . . 453
7.31 Future library directions . . . . . . . . . . . . . . . . . . . 455
7.31.1 Complex arithmetic <complex.h> . . . . . . . . . . . 455
7.31.2 Character handling <ctype.h> . . . . . . . . . . . . 455
7.31.3 Errors <errno.h> . . . . . . . . . . . . . . . . . 455
7.31.4 Floating-point environment <fenv.h> . . . . . . . . . . 455
7.31.5 Format conversion of integer types <inttypes.h> . . . . 455
7.31.6 Localization <locale.h> . . . . . . . . . . . . . . 455
7.31.7 Signal handling <signal.h> . . . . . . . . . . . . . 455
7.31.8 Atomics <stdatomic.h> . . . . . . . . . . . . . . 455
7.31.9 Boolean type and values <stdbool.h> . . . . . . . . . 456
7.31.10 Integer types <stdint.h> . . . . . . . . . . . . . . 456
7.31.11 Input/output <stdio.h> . . . . . . . . . . . . . . . 456
7.31.12 General utilities <stdlib.h> . . . . . . . . . . . . . 456
 7.31.13 String handling <string.h> . . . . . . . . . . . . . 456
7.31.14 Date and time <time.h> . . . . . . . . . . . . . . . 456
7.31.15 Threads <threads.h> . . . . . . . . . . . . . . . . 456
7.31.16 Extended multibyte and wide character utilities
<wchar.h> . . . . . . . . . . . . . . . . . . . . 456
7.31.17 Wide character classification and mapping utilities
<wctype.h> . . . . . . . . . . . . . . . . . . . . 457
Annex A (informative) Language syntax summary . . . . . . . . . . . . 458
A.1 Lexical grammar . . . . . . . . . . . . . . . . . . . . . . 458
A.2 Phrase structure grammar . . . . . . . . . . . . . . . . . . . 465
A.3 Preprocessing directives . . . . . . . . . . . . . . . . . . . 473
Annex B (informative) Library summary . . . . . . . . . . . . . . . . 475
B.1 Diagnostics <assert.h> . . . . . . . . . . . . . . . . . . 475
B.2 Complex <complex.h> . . . . . . . . . . . . . . . . . . . 475
B.3 Character handling <ctype.h> . . . . . . . . . . . . . . . . 477
B.4 Errors <errno.h> . . . . . . . . . . . . . . . . . . . . . 477
B.5 Floating-point environment <fenv.h> . . . . . . . . . . . . . 477
B.6 Characteristics of floating types <float.h> . . . . . . . . . . . 478
B.7 Format conversion of integer types <inttypes.h> . . . . . . . . 478
B.8 Alternative spellings <iso646.h> . . . . . . . . . . . . . . . 479
B.9 Sizes of integer types <limits.h> . . . . . . . . . . . . . . 479
B.10 Localization <locale.h> . . . . . . . . . . . . . . . . . . 479
B.11 Mathematics <math.h> . . . . . . . . . . . . . . . . . . . 479
B.12 Nonlocal jumps <setjmp.h> . . . . . . . . . . . . . . . . 484
B.13 Signal handling <signal.h> . . . . . . . . . . . . . . . . . 484
B.14 Alignment <stdalign.h> . . . . . . . . . . . . . . . . . 485
B.15 Variable arguments <stdarg.h> . . . . . . . . . . . . . . . 485
B.16 Atomics <stdatomic.h> . . . . . . . . . . . . . . . . . . 485
B.17 Boolean type and values <stdbool.h> . . . . . . . . . . . . 487
B.18 Common definitions <stddef.h> . . . . . . . . . . . . . . . 487
B.19 Integer types <stdint.h> . . . . . . . . . . . . . . . . . . 487
B.20 Input/output <stdio.h> . . . . . . . . . . . . . . . . . . 488
B.21 General utilities <stdlib.h> . . . . . . . . . . . . . . . . 491
B.22 _Noreturn <stdnoreturn.h> . . . . . . . . . . . . . . 493
B.23 String handling <string.h> . . . . . . . . . . . . . . . . . 493
B.24 Type-generic math <tgmath.h> . . . . . . . . . . . . . . . 495
B.25 Threads <threads.h> . . . . . . . . . . . . . . . . . . . 495
B.26 Date and time <time.h> . . . . . . . . . . . . . . . . . . 496
B.27 Unicode utilities <uchar.h> . . . . . . . . . . . . . . . . . 497
B.28 Extended multibyte/wide character utilities <wchar.h> . . . . . . 497
B.29 Wide character classification and mapping utilities <wctype.h> . . . 502
Annex C (informative) Sequence points . . . . . . . . . . . . . . . . . 503
Annex D (normative) Universal character names for identifiers . . . . . . . 504
D.1 Ranges of characters allowed . . . . . . . . . . . . . . . . . 504
D.2 Ranges of characters disallowed initially . . . . . . . . . . . . . 504
Annex E (informative) Implementation limits . . . . . . . . . . . . . . 505
Annex F (normative) IEC 60559 floating-point arithmetic . . . . . . . . . . 507
F.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 507
F.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
F.3 Operators and functions . . . . . . . . . . . . . . . . . . . 508
F.4 Floating to integer conversion . . . . . . . . . . . . . . . . . 510
F.5 Binary-decimal conversion . . . . . . . . . . . . . . . . . . 510
F.6 The return statement . . . . . . . . . . . . . . . . . . . . 511
F.7 Contracted expressions . . . . . . . . . . . . . . . . . . . . 511
F.8 Floating-point environment . . . . . . . . . . . . . . . . . . 511
F.9 Optimization . . . . . . . . . . . . . . . . . . . . . . . . 514
F.10 Mathematics <math.h> . . . . . . . . . . . . . . . . . . . 517
F.10.1 Trigonometric functions . . . . . . . . . . . . . . . . 518
F.10.2 Hyperbolic functions . . . . . . . . . . . . . . . . . 520
F.10.3 Exponential and logarithmic functions . . . . . . . . . . 520
F.10.4 Power and absolute value functions . . . . . . . . . . . 524
F.10.5 Error and gamma functions . . . . . . . . . . . . . . . 525
F.10.6 Nearest integer functions . . . . . . . . . . . . . . . . 526
F.10.7 Remainder functions . . . . . . . . . . . . . . . . . 528
F.10.8 Manipulation functions . . . . . . . . . . . . . . . . 529
F.10.9 Maximum, minimum, and positive difference functions . . . 530
F.10.10 Floating multiply-add . . . . . . . . . . . . . . . . . 530
F.10.11 Comparison macros . . . . . . . . . . . . . . . . . . 531
Annex G (normative) IEC 60559-compatible complex arithmetic . . . . . . . 532
G.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 532
G.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
G.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 532
G.4 Conversions . . . . . . . . . . . . . . . . . . . . . . . . 533
G.4.1 Imaginary types . . . . . . . . . . . . . . . . . . . 533
G.4.2 Real and imaginary . . . . . . . . . . . . . . . . . . 533
G.4.3 Imaginary and complex . . . . . . . . . . . . . . . . 533
G.5 Binary operators . . . . . . . . . . . . . . . . . . . . . . 533
G.5.1 Multiplicative operators . . . . . . . . . . . . . . . . 534
G.5.2 Additive operators . . . . . . . . . . . . . . . . . . 537
G.6 Complex arithmetic <complex.h> . . . . . . . . . . . . . . 537
G.6.1 Trigonometric functions . . . . . . . . . . . . . . . . 539
G.6.2 Hyperbolic functions . . . . . . . . . . . . . . . . . 539
G.6.3 Exponential and logarithmic functions . . . . . . . . . . 543
G.6.4 Power and absolute-value functions . . . . . . . . . . . 544
G.7 Type-generic math <tgmath.h> . . . . . . . . . . . . . . . 545
Annex H (informative) Language independent arithmetic . . . . . . . . . . 546
H.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 546
H.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
H.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 550
Annex I (informative) Common warnings . . . . . . . . . . . . . . . . 552
Annex J (informative) Portability issues . . . . . . . . . . . . . . . . . 554
J.1 Unspecified behavior . . . . . . . . . . . . . . . . . . . . . 554
J.2 Undefined behavior . . . . . . . . . . . . . . . . . . . . . 557
J.3 Implementation-defined behavior . . . . . . . . . . . . . . . . 571
J.4 Locale-specific behavior . . . . . . . . . . . . . . . . . . . 578
J.5 Common extensions . . . . . . . . . . . . . . . . . . . . . 579
Annex K (normative) Bounds-checking interfaces . . . . . . . . . . . . . 582
K.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 582
K.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
K.3 Library . . . . . . . . . . . . . . . . . . . . . . . . . . 583
K.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . 583
K.3.1.1 Standard headers . . . . . . . . . . . . . . . 583
K.3.1.2 Reserved identifiers . . . . . . . . . . . . . . 584
K.3.1.3 Use of errno . . . . . . . . . . . . . . . . . 584
K.3.1.4 Runtime-constraint violations . . . . . . . . . . 584
K.3.2 Errors <errno.h> . . . . . . . . . . . . . . . . . 585
K.3.3 Common definitions <stddef.h> . . . . . . . . . . . 585
K.3.4 Integer types <stdint.h> . . . . . . . . . . . . . . 585
K.3.5 Input/output <stdio.h> . . . . . . . . . . . . . . . 586
K.3.5.1 Operations on files . . . . . . . . . . . . . . 586
K.3.5.2 File access functions . . . . . . . . . . . . . . 588
K.3.5.3 Formatted input/output functions . . . . . . . . . 591
K.3.5.4 Character input/output functions . . . . . . . . . 602
K.3.6 General utilities <stdlib.h> . . . . . . . . . . . . . 604
K.3.6.1 Runtime-constraint handling . . . . . . . . . . 604
K.3.6.2 Communication with the environment . . . . . . . 606
K.3.6.3 Searching and sorting utilities . . . . . . . . . . 607
K.3.6.4 Multibyte/wide character conversion functions . . . 610
K.3.6.5 Multibyte/wide string conversion functions . . . . . 611
K.3.7 String handling <string.h> . . . . . . . . . . . . . 614
K.3.7.1 Copying functions . . . . . . . . . . . . . . 614
K.3.7.2 Concatenation functions . . . . . . . . . . . . 617
K.3.7.3 Search functions . . . . . . . . . . . . . . . 620
K.3.7.4 Miscellaneous functions . . . . . . . . . . . . 621
K.3.8 Date and time <time.h> . . . . . . . . . . . . . . . 624
K.3.8.1 Components of time . . . . . . . . . . . . . . 624
K.3.8.2 Time conversion functions . . . . . . . . . . . 624
 K.3.9 Extended multibyte and wide character utilities
<wchar.h> . . . . . . . . . . . . . . . . . . . . 627
K.3.9.1 Formatted wide character input/output functions . . . 628
K.3.9.2 General wide string utilities . . . . . . . . . . . 639
K.3.9.3 Extended multibyte/wide character conversion
utilities . . . . . . . . . . . . . . . . . . . 647
Annex L (normative) Analyzability . . . . . . . . . . . . . . . . . . 652
L.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
L.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 652
L.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 653
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
 Foreword
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. In the field of information technology, ISO and IEC have
established a joint technical committee, ISO/IEC JTC 1.
2 International Standards are drafted in accordance with the rules given in the ISO/IEC
Directives, Part 2.
3 The main task of the joint technical committee is to prepare International Standards.
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.
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.
5 ISO/IEC 9899 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 22, Programming languages, their environments and
system software interfaces.
6 This third edition cancels and replaces the second edition, ISO/IEC 9899:1999, which has
been technically revised. It also incorporates the Technical Corrigenda
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:
— conditional (optional) features (including some that were previously mandatory)
— support for multiple threads of execution including an improved memory sequencing
model, atomic objects, and thread-local storage (<stdatomic.h> and
<threads.h>)
— additional floating-point characteristic macros (<float.h>)
— querying and specifying alignment of objects (<stdalign.h>, <stdlib.h>)
— Unicode characters and strings (<uchar.h>) (originally specified in
ISO/IEC TR 19769:2004)
— type-generic expressions
— static assertions
— anonymous structures and unions
 — no-return functions
— macros to create complex numbers (<complex.h>)
— support for opening files for exclusive access
— removed the gets function (<stdio.h>)
— added the aligned_alloc, at_quick_exit, and quick_exit functions
(<stdlib.h>)
— (conditional) support for bounds-checking interfaces (originally specified in
ISO/IEC TR 24731−1:2007)
— (conditional) support for analyzability
7 Major changes in the second edition included:
— restricted character set support via digraphs and <iso646.h> (originally specified
in ISO/IEC 9899:1990/Amd.1:1995)
— wide character library support in <wchar.h> and <wctype.h> (originally
specified in ISO/IEC 9899:1990/Amd.1:1995)
— more precise aliasing rules via effective type
— restricted pointers
— variable length arrays
— flexible array members
— static and type qualifiers in parameter array declarators
— complex (and imaginary) support in <complex.h>
— type-generic math macros in <tgmath.h>
— the long long int type and library functions
— extended integer types
— increased minimum translation limits
— additional floating-point characteristics in <float.h>
— remove implicit int
— reliable integer division
— universal character names (\u and \U)
— extended identifiers
— hexadecimal floating-point constants and %a and %A printf/scanf conversion
specifiers
— compound literals
— designated initializers
— // comments
— specified width integer types and corresponding library functions in <inttypes.h>
and <stdint.h>
— remove implicit function declaration
— preprocessor arithmetic done in intmax_t/uintmax_t
— mixed declarations and statements
— new block scopes for selection and iteration statements
— integer constant type rules
— integer promotion rules
— macros with a variable number of arguments
— the vscanf family of functions in <stdio.h> and <wchar.h>
— additional math library functions in <math.h>
— treatment of error conditions by math library functions (math_errhandling)
— floating-point environment access in <fenv.h>
— IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
— trailing comma allowed in enum declaration
— %lf conversion specifier allowed in printf
— inline functions
— the snprintf family of functions in <stdio.h>
— boolean type in <stdbool.h>
— idempotent type qualifiers
— empty macro arguments
— new structure type compatibility rules (tag compatibility)
— additional predefined macro names
— _Pragma preprocessing operator
— standard pragmas
— _ _func_ _ predefined identifier
— va_copy macro
— additional strftime conversion specifiers
— LIA compatibility annex
— deprecate ungetc at the beginning of a binary file
— remove deprecation of aliased array parameters
— conversion of array to pointer not limited to lvalues
— relaxed constraints on aggregate and union initialization
— relaxed restrictions on portable header names
— return without expression not permitted in function that returns a value (and vice
versa)
 Introduction
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.
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 [6.11] or library features [7.31]) is discouraged.
3 This International Standard is divided into four major subdivisions:
— preliminary elements (clauses 1−4);
— the characteristics of environments that translate and execute C programs (clause 5);
— the language syntax, constraints, and semantics (clause 6);
— the library facilities (clause 7).
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.
5 The language clause (clause 6) is derived from ‘‘The C Reference Manual’’.
6 The library clause (clause 7) is based on the 1984 /usr/group Standard.
7 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.
 INTERNATIONAL STANDARD ©ISO/IEC ISO/IEC 9899:2011 (E)

Information technology — Programming languages — C

1. Scope
1 This International Standard specifies the form and establishes the interpretation of
programs written in the C programming language.1) It specifies
— the representation of C programs;
— the syntax and constraints of the C language;
— the semantic rules for interpreting C programs;
— the representation of input data to be processed by C programs;
— the representation of output data produced by C programs;
— the restrictions and limits imposed by a conforming implementation of C.
2 This International Standard does not specify
— the mechanism by which C programs are transformed for use by a data-processing
system;
— the mechanism by which C programs are invoked for use by a data-processing
system;
— the mechanism by which input data are transformed for use by a C program;
— the mechanism by which output data are transformed after being produced by a C
program;
— the size or complexity of a program and its data that will exceed the capacity of any
specific data-processing system or the capacity of a particular processor;
— all minimal requirements of a data-processing system that is capable of supporting a
conforming implementation.

1) 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.

§1 General 1
 2. Normative references
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.
2 ISO/IEC 2382−1:1993, Information technology — Vocabulary — Part 1: Fundamental
terms.
3 ISO 4217, Codes for the representation of currencies and funds.
4 ISO 8601, Data elements and interchange formats — Information interchange —
Representation of dates and times.
5 ISO/IEC 10646, Information technology — Universal Coded Character Set (UCS).
6 IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems (previously
designated IEC 559:1989).
7 ISO 80000−2, Quantities and units — Part 2: Mathematical signs and symbols to be used
in the natural sciences and technology.

2 General §2
 3. Terms, definitions, and symbols
1 For the purposes of this document, the following terms and 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 80000−2.
3.1
1 access
〈execution-time action〉 to read or modify the value of an object
2 NOTE 1 Where only one of these two actions is meant, ‘‘read’’ or ‘‘modify’’ is used.

3 NOTE 2 ‘‘Modify’’ includes the case where the new value being stored is the same as the previous value.

4 NOTE 3 Expressions that are not evaluated do not access objects.

3.2
1 alignment
requirement that objects of a particular type be located on storage boundaries with
addresses that are particular multiples of a byte address
3.3
1 argument
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
3.4
1 behavior
external appearance or action
3.4.1
1 implementation-defined behavior
unspecified behavior where each implementation documents how the choice is made
2 EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit
when a signed integer is shifted right.

3.4.2
1 locale-specific behavior
behavior that depends on local conventions of nationality, culture, and language that each
implementation documents

§3.4.2 General 3
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

2 EXAMPLE An example of locale-specific behavior is whether the islower function returns true for
characters other than the 26 lowercase Latin letters.

3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements
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).

3 EXAMPLE An example of undefined behavior is the behavior on integer overflow.

3.4.4
1 unspecified behavior
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
2 EXAMPLE An example of unspecified behavior is the order in which the arguments to a function are
evaluated.

3.5
1 bit
unit of data storage in the execution environment large enough to hold an object that may
have one of two values
2 NOTE It need not be possible to express the address of each individual bit of an object.

3.6
1 byte
addressable unit of data storage large enough to hold any member of the basic character
set of the execution environment
2 NOTE 1 It is possible to express the address of each individual byte of an object uniquely.

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.

3.7
1 character
〈abstract〉 member of a set of elements used for the organization, control, or
representation of data
3.7.1
1 character
single-byte character
〈C〉 bit representation that fits in a byte
4 General §3.7.1
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

3.7.2
1 multibyte character
sequence of one or more bytes representing a member of the extended character set of
either the source or the execution environment
2 NOTE The extended character set is a superset of the basic character set.

3.7.3
1 wide character
value representable by an object of type wchar_t, capable of representing any character
in the current locale
3.8
1 constraint
restriction, either syntactic or semantic, by which the exposition of language elements is
to be interpreted
3.9
1 correctly rounded result
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
3.10
1 diagnostic message
message belonging to an implementation-defined subset of the implementation’s message
output
3.11
1 forward reference
reference to a later subclause of this International Standard that contains additional
information relevant to this subclause
3.12
1 implementation
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
3.13
1 implementation limit
restriction imposed upon programs by the implementation
3.14
1 memory location
either an object of scalar type, or a maximal sequence of adjacent bit-fields all having
nonzero width

§3.14 General 5
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

2 NOTE 1 Two threads of execution can update and access separate memory locations without interfering
with each other.

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.

4 EXAMPLE A structure declared as

struct {
char a;
int b:5, c:11, :0, d:8;
struct { int ee:8; } e;
}
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.

3.15
1 object
region of data storage in the execution environment, the contents of which can represent
values
2 NOTE When referenced, an object may be interpreted as having a particular type; see 6.3.2.1.

3.16
1 parameter
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
3.17
1 recommended practice
specification that is strongly recommended as being in keeping with the intent of the
standard, but that may be impractical for some implementations
3.18
1 runtime-constraint
requirement on a program when calling a library function
2 NOTE 1 Despite the similar terms, a runtime-constraint is not a kind of constraint as defined by 3.8, and
need not be diagnosed at translation time.

3 NOTE 2 Implementations that support the extensions in annex K are required to verify that the runtime-
constraints for a library function are not violated by the program; see K.3.1.4.

6 General §3.18
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

3.19
1 value
precise meaning of the contents of an object when interpreted as having a specific type
3.19.1
1 implementation-defined value
unspecified value where each implementation documents how the choice is made
3.19.2
1 indeterminate value
either an unspecified value or a trap representation
3.19.3
1 unspecified value
valid value of the relevant type where this International Standard imposes no
requirements on which value is chosen in any instance
2 NOTE An unspecified value cannot be a trap representation.

3.19.4
1 trap representation
an object representation that need not represent a value of the object type
3.19.5
1 perform a trap
interrupt execution of the program such that no further operations are performed
2 NOTE In this International Standard, when the word ‘‘trap’’ is not immediately followed by
‘‘representation’’, this is the intended usage.2)

3.20
1 ⎡ x⎤
ceiling of x: the least integer greater than or equal to x
2 EXAMPLE ⎡2. 4⎤ is 3, ⎡−2. 4⎤ is −2.

3.21
1 ⎣ x⎦
floor of x: the greatest integer less than or equal to x
2 EXAMPLE ⎣2. 4⎦ is 2, ⎣−2. 4⎦ is −3.

2) For example, ‘‘Trapping or stopping (if supported) is disabled...’’ (F.8.2). Note that fetching a trap
representation might perform a trap but is not required to (see 6.2.6.1).

§3.21 General 7
 4. Conformance
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.
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’’.
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 5.1.2.3.
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.
5 A strictly conforming program shall use only those features of the language and library
specified in this International Standard.3) It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior, and shall not exceed any
minimum implementation limit.
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 <float.h>, <iso646.h>, <limits.h>, <stdalign.h>,
<stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and
<stdnoreturn.h>. A conforming implementation may have extensions (including
additional library functions), provided they do not alter the behavior of any strictly
conforming program.4)

3) A strictly conforming program can use conditional features (see 6.10.8.3) provided the use is guarded
by an appropriate conditional inclusion preprocessing directive using the related macro. For example:
#ifdef _ _STDC_IEC_559_ _ /* FE_UPWARD defined */
/* ... */
fesetround(FE_UPWARD);
/* ... */
#endif

4) This implies that a conforming implementation reserves no identifiers other than those explicitly
reserved in this International Standard.

8 General §4
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

7 A conforming program is one that is acceptable to a conforming implementation.5)

8 An implementation shall be accompanied by a document that defines all implementation-
defined and locale-specific characteristics and all extensions.
Forward references: conditional inclusion (6.10.1), error directive (6.10.5),
characteristics of floating types <float.h> (7.7), alternative spellings <iso646.h>
(7.9), sizes of integer types <limits.h> (7.10), alignment <stdalign.h> (7.15),
variable arguments <stdarg.h> (7.16), boolean type and values <stdbool.h>
(7.18), common definitions <stddef.h> (7.19), integer types <stdint.h> (7.20),
<stdnoreturn.h> (7.23).

5) Strictly conforming programs are intended to be maximally portable among conforming

implementations. Conforming programs may depend upon nonportable features of a conforming
implementation.

§4 General 9
 5. Environment
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.
Forward references: In this clause, only a few of many possible forward references
have been noted.
5.1 Conceptual models
5.1.1 Translation environment
5.1.1.1 Program structure
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.
Forward references: linkages of identifiers (6.2.2), external definitions (6.9),
preprocessing directives (6.10).
5.1.1.2 Translation phases
1 The precedence among the syntax rules of translation is specified by the following
phases.6)
1. 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.

6) 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.

10 Environment §5.1.1.2
© ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

2. 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.
3. The source file is decomposed into preprocessing tokens7) 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.
4. 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 (6.10.3.3), 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.
5. 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.8)
6. Adjacent string literal tokens are concatenated.
7. 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.
8. All external object and function references are resolved. Library components are
linked to satisfy external references to functions and objects not defined in the
current translation. All such translator output is collected into a program image
which contains information needed for execution in its execution environment.
Forward references: universal character names (6.4.3), lexical elements (6.4),
preprocessing directives (6.10), trigraph sequences (5.2.1.1), external definitions (6.9).

7) As described in 6.4, the process of dividing a source file’s characters into preprocessing tokens is
context-dependent. For example, see the handling of < within a #include preprocessing directive.
8) An implementation need not convert all non-corresponding source characters to the same execution
character.

§5.1.1.2 Environment 11
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

5.1.1.3 Diagnostics
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.9)
2 EXAMPLE An implementation is required to issue a diagnostic for the translation unit:
char i;
int i;
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.

5.1.2 Execution environments

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.
Forward references: storage durations of objects (6.2.4), initialization (6.7.9).
5.1.2.1 Freestanding environment
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.
2 The effect of program termination in a freestanding environment is implementation-
defined.
5.1.2.2 Hosted environment
1 A hosted environment need not be provided, but shall conform to the following
specifications if present.

9) 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.

12 Environment §5.1.2.2
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

5.1.2.2.1 Program startup

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:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent;10) or in some other implementation-defined manner.
2 If they are declared, the parameters to the main function shall obey the following
constraints:
— The value of argc shall be nonnegative.
— argv[argc] shall be a null pointer.
— If the value of argc is greater than zero, the array members argv[0] through
argv[argc-1] inclusive shall contain pointers to strings, which are given
implementation-defined values by the host environment prior to program startup. The
intent is to supply to the program information determined prior to program startup
from elsewhere in the hosted environment. If the host environment is not capable of
supplying strings with letters in both uppercase and lowercase, the implementation
shall ensure that the strings are received in lowercase.
— If the value of argc is greater than zero, the string pointed to by argv[0]
represents the program name; argv[0][0] shall be the null character if the
program name is not available from the host environment. If the value of argc is
greater than one, the strings pointed to by argv[1] through argv[argc-1]
represent the program parameters.
— The parameters argc and argv and the strings pointed to by the argv array shall
be modifiable by the program, and retain their last-stored values between program
startup and program termination.
5.1.2.2.2 Program execution
1 In a hosted environment, a program may use all the functions, macros, type definitions,
and objects described in the library clause (clause 7).

10) 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.

§5.1.2.2.2 Environment 13
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

5.1.2.2.3 Program termination

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;11) 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.
Forward references: definition of terms (7.1.1), the exit function (7.22.4.4).
5.1.2.3 Program execution
1 The semantic descriptions in this International Standard describe the behavior of an
abstract machine in which issues of optimization are irrelevant.
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,12) 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.
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.13) 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 annex C.)
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

11) In accordance with 6.2.4, 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.
12) 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 annex F for details. The floating-point
environment library <fenv.h> provides a programming facility for indicating when these side
effects matter, freeing the implementations in other cases.
13) The executions of unsequenced evaluations can interleave. Indeterminately sequenced evaluations
cannot interleave, but can be executed in any order.

14 Environment §5.1.2.3
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

calling a function or accessing a volatile object).

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.
6 The least requirements on a conforming implementation are:
— Accesses to volatile objects are evaluated strictly according to the rules of the abstract
machine.
— At program termination, all data written into files shall be identical to the result that
execution of the program according to the abstract semantics would have produced.
— The input and output dynamics of interactive devices shall take place as specified in
7.21.3. The intent of these requirements is that unbuffered or line-buffered output
appear as soon as possible, to ensure that prompting messages actually appear prior to
a program waiting for input.
This is the observable behavior of the program.
7 What constitutes an interactive device is implementation-defined.
8 More stringent correspondences between abstract and actual semantics may be defined by
each implementation.
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.
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.

11 EXAMPLE 2 In executing the fragment

char c1, c2;
/* ... */
c1 = c1 + c2;
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
§5.1.2.3 Environment 15
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only
produce the same result, possibly omitting the promotions.

12 EXAMPLE 3 Similarly, in the fragment

float f1, f2;
double d;
/* ... */
f1 = f2 * d;
the multiplication may be executed using single-precision arithmetic if the implementation can ascertain
that the result would be the same as if it were executed using double-precision arithmetic (for example, if d
were replaced by the constant 2.0, which has type double).

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
double d1, d2;
float f;
d1 = f = expression;
d2 = (float) expression;
the values assigned to d1 and d2 are required to have been converted to float.

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 F.9).
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;

15 EXAMPLE 6 To illustrate the grouping behavior of expressions, in the following fragment

int a, b;
/* ... */
a = a + 32760 + b + 5;
the expression statement behaves exactly the same as
a = (((a + 32760) + b) + 5);
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
a = ((a + b) + 32765);
since if the values for a and b were, respectively, −32754 and −15, the sum a + b would produce a trap

16 Environment §5.1.2.3
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

while the original expression would not; nor can the expression be rewritten either as
a = ((a + 32765) + b);
or
a = (a + (b + 32765));
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.

16 EXAMPLE 7 The grouping of an expression does not completely determine its evaluation. In the
following fragment
#include <stdio.h>
int sum;
char *p;
/* ... */
sum = sum * 10 - '0' + (*p++ = getchar());
the expression statement is grouped as if it were written as
sum = (((sum * 10) - '0') + ((*(p++)) = (getchar())));
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.

Forward references: expressions (6.5), type qualifiers (6.7.3), statements (6.8), floating-
point environment <fenv.h> (7.6), the signal function (7.14), files (7.21.3).
5.1.2.4 Multi-threaded executions and data races
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.14) Under a freestanding implementation, it is
implementation-defined whether a program can have more than one thread of execution.
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.
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.

4 Two expression evaluations conflict if one of them modifies a memory location and the
other one reads or modifies the same memory location.

14) 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.

§5.1.2.4 Environment 17
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

5 The library defines a number of atomic operations (7.17) and operations on mutexes
(7.26.4) 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.
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.

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.
8 NOTE 3 This states that the modification orders must respect the ‘‘happens before’’ relation.

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.

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.
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.
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.

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.

14 An evaluation A carries a dependency 15) to an evaluation B if:

15) The ‘‘carries a dependency’’ relation is a subset of the ‘‘sequenced before’’ relation, and is similarly
strictly intra-thread.

18 Environment §5.1.2.4
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

— the value of A is used as an operand of B, unless:

• B is an invocation of the kill_dependency macro,
• A is the left operand of a && or || operator,
• A is the left operand of a ? : operator, or
• A is the left operand of a , operator;
or
— 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
— for some evaluation X, A carries a dependency to X and X carries a dependency to B.
15 An evaluation A is dependency-ordered before16) an evaluation B if:
— 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
— for some evaluation X, A is dependency-ordered before X and X carries a
dependency to B.
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:
— A synchronizes with X and X is sequenced before B,
— A is sequenced before X and X inter-thread happens before B, or
— A inter-thread happens before X and X inter-thread happens before B.
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’’.

18 An evaluation A happens before an evaluation B if A is sequenced before B or A inter-

thread happens before B.

16) The ‘‘dependency-ordered before’’ relation is analogous to the ‘‘synchronizes with’’ relation, but uses
release/consume in place of release/acquire.

§5.1.2.4 Environment 19
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

19 A visible side effect A on an object M with respect to a value computation B of M

satisfies the conditions:
— A happens before B, and
— there is no other side effect X to M such that A happens before X and X happens
before B.
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.
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.

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.

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.
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.

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.

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.
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.

20 Environment §5.1.2.4
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

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.

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.

§5.1.2.4 Environment 21
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

5.2 Environmental considerations

5.2.1 Character sets
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.
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.
3 Both the basic source and basic execution character sets shall have the following
members: the 26 uppercase letters of the Latin alphabet
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
the 26 lowercase letters of the Latin alphabet
a b c d e f g h i j k l m
n o p q r s t u v w x y z
the 10 decimal digits
0 1 2 3 4 5 6 7 8 9
the following 29 graphic characters
! " # % & ' ( ) * + , - . / :
; < = > ? [ \ ] ^ _ { | } ~
the space character, and control characters representing horizontal tab, vertical tab, and
form feed. 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

22 Environment §5.2.1
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

converted to a token), the behavior is undefined.

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.
5 The universal character name construct provides a way to name other characters.
Forward references: universal character names (6.4.3), character constants (6.4.4.4),
preprocessing directives (6.10), string literals (6.4.5), comments (6.4.9), string (7.1.1).
5.2.1.1 Trigraph sequences
1 Before any other processing takes place, each occurrence of one of the following
sequences of three characters (called trigraph sequences17)) is replaced with the
corresponding single character.
??= # ??) ] ??! |
??( [ ??' ^ ??> }
??/ \ ??< { ??- ~
No other trigraph sequences exist. Each ? that does not begin one of the trigraphs listed
above is not changed.
2 EXAMPLE 1
??=define arraycheck(a, b) a??(b??) ??!??! b??(a??)
becomes
#define arraycheck(a, b) a[b] || b[a]

3 EXAMPLE 2 The following source line

printf("Eh???/n");
becomes (after replacement of the trigraph sequence ??/)
printf("Eh?\n");

5.2.1.2 Multibyte characters

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:
— The basic character set shall be present and each character shall be encoded as a
single byte.
— The presence, meaning, and representation of any additional members is locale-
specific.

17) 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.

§5.2.1.2 Environment 23
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

— 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.
— 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.
2 For source files, the following shall hold:
— An identifier, comment, string literal, character constant, or header name shall begin
and end in the initial shift state.
— An identifier, comment, string literal, character constant, or header name shall consist
of a sequence of valid multibyte characters.
5.2.2 Character display semantics
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.
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
the active position is at the initial position of a line, the behavior of the display
device is unspecified.
\f ( form feed) Moves the active position to the initial position at the start of the next
logical page.
\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
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.
\v (vertical tab) Moves the active position to the initial position of the next vertical
tabulation position. If the active position is at or past the last defined vertical
24 Environment §5.2.2
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

tabulation position, the behavior of the display device is unspecified.

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.
Forward references: the isprint function (7.4.1.8), the fputc function (7.21.7.3).
5.2.3 Signals and interrupts
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.
5.2.4 Environmental limits
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.
5.2.4.1 Translation limits
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:18)
— 127 nesting levels of blocks
— 63 nesting levels of conditional inclusion
— 12 pointer, array, and function declarators (in any combinations) modifying an
arithmetic, structure, union, or void type in a declaration
— 63 nesting levels of parenthesized declarators within a full declarator
— 63 nesting levels of parenthesized expressions within a full expression
— 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)
— 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

18) Implementations should avoid imposing fixed translation limits whenever possible.

§5.2.4.1 Environment 25
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

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)19)
— 4095 external identifiers in one translation unit
— 511 identifiers with block scope declared in one block
— 4095 macro identifiers simultaneously defined in one preprocessing translation unit
— 127 parameters in one function definition
— 127 arguments in one function call
— 127 parameters in one macro definition
— 127 arguments in one macro invocation
— 4095 characters in a logical source line
— 4095 characters in a string literal (after concatenation)
— 65535 bytes in an object (in a hosted environment only)
— 15 nesting levels for #included files
— 1023 case labels for a switch statement (excluding those for any nested switch
statements)
— 1023 members in a single structure or union
— 1023 enumeration constants in a single enumeration
— 63 levels of nested structure or union definitions in a single struct-declaration-list
5.2.4.2 Numerical limits
1 An implementation is required to document all the limits specified in this subclause,
which are specified in the headers <limits.h> and <float.h>. Additional limits are
specified in <stdint.h>.
Forward references: integer types <stdint.h> (7.20).
5.2.4.2.1 Sizes of integer types <limits.h>
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

19) See ‘‘future language directions’’ (6.11.3).

26 Environment §5.2.4.2.1
© ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

(absolute value) to those shown, with the same sign.

— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
— minimum value for an object of type signed char
SCHAR_MIN -127 // −(27 − 1)
— maximum value for an object of type signed char
SCHAR_MAX +127 // 27 − 1
— maximum value for an object of type unsigned char
UCHAR_MAX 255 // 28 − 1
— minimum value for an object of type char
CHAR_MIN see below
— maximum value for an object of type char
CHAR_MAX see below
— maximum number of bytes in a multibyte character, for any supported locale
MB_LEN_MAX 1
— minimum value for an object of type short int
SHRT_MIN -32767 // −(215 − 1)
— maximum value for an object of type short int
SHRT_MAX +32767 // 215 − 1
— maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216 − 1
— minimum value for an object of type int
INT_MIN -32767 // −(215 − 1)
— maximum value for an object of type int
INT_MAX +32767 // 215 − 1
— maximum value for an object of type unsigned int
UINT_MAX 65535 // 216 − 1
— minimum value for an object of type long int
LONG_MIN -2147483647 // −(231 − 1)
— maximum value for an object of type long int
LONG_MAX +2147483647 // 231 − 1
— maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 232 − 1

§5.2.4.2.1 Environment 27
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

— minimum value for an object of type long long int

LLONG_MIN -9223372036854775807 // −(263 − 1)
— maximum value for an object of type long long int
LLONG_MAX +9223372036854775807 // 263 − 1
— maximum value for an object of type unsigned long long int
ULLONG_MAX 18446744073709551615 // 264 − 1
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.20) The value UCHAR_MAX shall equal 2CHAR_BIT − 1.
Forward references: representations of types (6.2.6), conditional inclusion (6.10.1).
5.2.4.2.2 Characteristics of floating types <float.h>
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.21) The following parameters are used to
define the model for each floating-point type:
s sign (±1)
b base or radix of exponent representation (an integer > 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)
2 A floating-point number (x) is defined by the following model:
p
x = sb e Σ
k=1
f k b−k , emin ≤ e ≤ emax

3 In addition to normalized floating-point numbers ( f 1 > 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 > 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

20) See 6.2.5.

21) 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.

28 Environment §5.2.4.2.2
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

arithmetic operand.22)
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.
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.
6 The accuracy of the floating-point operations (+, -, *, /) and of the library functions in
<math.h> and <complex.h> 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
<stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state that the
accuracy is unknown.
7 All integer values in the <float.h> 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.
8 The rounding mode for floating-point addition is characterized by the implementation-
defined value of FLT_ROUNDS:23)
-1 indeterminable
0 toward zero
1 to nearest
2 toward positive infinity
3 toward negative infinity
All other values for FLT_ROUNDS characterize implementation-defined rounding
behavior.

22) 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.
23) Evaluation of FLT_ROUNDS correctly reflects any execution-time change of rounding mode through
the function fesetround in <fenv.h>.

§5.2.4.2.2 Environment 29
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

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:24)
-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.
All other negative values for FLT_EVAL_METHOD characterize implementation-defined
behavior.
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:
-1 indeterminable25)
0 absent26) (type does not support subnormal numbers)
1 present (type does support subnormal numbers)
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:
— radix of exponent representation, b
FLT_RADIX 2

24) 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.
25) Characterization as indeterminable is intended if floating-point operations do not consistently interpret
subnormal representations as zero, nor as nonzero.
26) 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.

30 Environment §5.2.4.2.2
© ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

— number of base-FLT_RADIX digits in the floating-point significand, p

FLT_MANT_DIG
DBL_MANT_DIG
LDBL_MANT_DIG
— 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,
⎧ p log10 b if b is a power of 10
⎨
⎩ ⎡1 + p log10 b⎤ otherwise
FLT_DECIMAL_DIG 6
DBL_DECIMAL_DIG 10
LDBL_DECIMAL_DIG 10
— 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,
⎧ pmax log10 b if b is a power of 10
⎨
⎩ ⎡1 + pmax log10 b⎤ otherwise
DECIMAL_DIG 10
— 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,
⎧ p log10 b if b is a power of 10
⎨
⎩ ⎣( p − 1) log10 b⎦ otherwise
FLT_DIG 6
DBL_DIG 10
LDBL_DIG 10
— 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

§5.2.4.2.2 Environment 31
 ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

— minimum negative integer such that 10 raised to that power is in the range of
normalized floating-point numbers, ⎡log10 b emin −1 ⎤
⎢ ⎥
FLT_MIN_10_EXP -37
DBL_MIN_10_EXP -37
LDBL_MIN_10_EXP -37
— maximum integer such that FLT_RADIX raised to one less than that power is a
representable finite floating-point number, emax
FLT_MAX_EXP
DBL_MAX_EXP
LDBL_MAX_EXP
— maximum integer such that 10 raised to that power is in the range of representable
finite floating-point numbers, ⎣log10 ((1 − b− p )b emax )⎦
FLT_MAX_10_EXP +37
DBL_MAX_10_EXP +37
LDBL_MAX_10_EXP +37
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:
— maximum representable finite floating-point number, (1 − b− p )b emax
FLT_MAX 1E+37
DBL_MAX 1E+37
LDBL_MAX 1E+37
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:
— the difference between 1 and the least value greater than 1 that is representable in the
given floating point type, b1− p
FLT_EPSILON 1E-5
DBL_EPSILON 1E-9
LDBL_EPSILON 1E-9
— minimum normalized positive floating-point number, b emin −1
FLT_MIN 1E-37
DBL_MIN 1E-37
LDBL_MIN 1E-37

32 Environment §5.2.4.2.2
 © ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E)

— minimum positive floating-point number27)

FLT_TRUE_MIN 1E-37
DBL_TRUE_MIN 1E-37
LDBL_TRUE_MIN 1E-37
Recommended practice
14 Conversion from (at least) double to decimal with DECIMAL_DIG digits and back
should be the identity function.
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 <float.h> header for type
float:
6
x = s16e Σ
k=1
f k 16−k , −31 ≤ e ≤ +32

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

16 EXAMPLE 2 The following describes floating-point representations that also meet the requirements for
single-precision and double-precision numbers in IEC 60559,28) and the appropriate values in a
<float.h> header for types float and double:
24
x f = s2e Σ
k=1
f k 2−k , −125 ≤ e ≤ +128

53
x d = s2e Σ
k=1
f k 2−k , −1021 ≤ e ≤ +1024

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

27) 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.
28) 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.

§5.2.4.2.2 Environment 33
ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved

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
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.

Forward references: conditional inclusion (6.10.1), complex arithmetic

<complex.h> (7.3), extended multibyte and wide character utilities <wchar.h>
(7.29), floating-point environment <fenv.h> (7.6), general utilities <stdlib.h>
(7.22), input/output <stdio.h> (7.21), mathematics <math.h> (7.12).

34 Environment §5.2.4.2.2
Exploring the Variety of Random
Documents with Different Content
 However, there are dangerous mountain-top winds of one kind, or,
more properly, numerous local air-blasts, that are sometimes created
within these high winds, that do not appear to have any habits. It
would be easier to tell where the next thunderbolt would fall than
where the next one of these would explode. One of these might be
called a cannon wind. An old prospector, who had experienced
countless high winds among the crags, once stated that high, gusty
winds on mountain-slopes "sometimes shoot off a cannon." These
explosive blasts touch only a short, narrow space, but in this they
are almost irresistible.
Isolated clouds often soften and beautify the stern heights as they
silently float and drift among peaks and passes. Flocks of these sky
birds frequently float about together. On sunny days, in addition to
giving a charm to the peaks, their restless shadows never tire of
readjusting themselves and are ever trying to find a foundation or a
place of rest upon the tempestuous topography of the heights
below. Now and then a deep, dense cloud-stratum will cover the
crests and envelop the summit slopes for days. These vapory strata
usually feel but little wind and they vary in thickness from a few
hundred to a few thousand feet. Sometimes one of these rests so
serenely that it suggests an aggregation of clouds pushed off to one
side because temporarily the sky does not need them elsewhere for
either decorative or precipitative purposes. Now and then they do
drop rain or snow, but most of the time they appear to be in a
procrastinating mood and unable to decide whether to precipitate or
to move on.
Commonly the upper surfaces of cloud-strata appear like a
peaceful silver-gray sea. They appear woolly and sometimes fluffy,
level, and often so vast that they sweep away beyond the horizon.
Peaks and ridges often pierce their interminable surface with
romantic continents and islands; along their romantic shores, above
the surface of the picturesque sea, the airship could sail in safe
poetic flight, though the foggy depths below were too dense for any
traveler to penetrate.
 One spring the snow fell continuously around my cabin for three
days. Reports told that the storm was general over the Rocky
Mountain region. Later investigations showed that that cloud and
storm were spread over a quarter of a million square miles. Over this
entire area there was made a comparatively even deposit of thirty
inches of snow.
All over the area, the bottom, or under surface, of the cloud was
at an altitude of approximately nine thousand feet. My cabin, with an
altitude of nine thousand, was immersed in cloud, though at times it
was one hundred feet or so below it. Fully satisfied of the
widespread and general nature of the storm, and convinced of the
comparatively level line of the bottom surface of the cloud, I
determined to measure its vertical depth and observe its slow
movements by climbing above its silver lining. This was the third day
of the storm. On snowshoes up the mountainside I went through
this almost opaque sheep's-wool cloud. It was not bitterly cold, but
cloud and snow combined were blinding, and only a ravine and
instinct enabled me to make my way.
At an altitude of about twelve thousand feet the depth of the
snow became suddenly less, soon falling to only an inch or so.
Within a few rods of where it began to grow shallow I burst through
the upper surface of the cloud. Around me and above there was not
a flake of snow. Over the entire storm-area of a quarter of a million
square miles, all heights above twelve thousand had escaped both
cloud and snow. The cloud, which thus lay between the altitudes of
nine thousand and twelve thousand feet, was three thousand feet
deep.
When I rose above the surface of this sea the sun was shining
upon it. It was a smooth sea; not a breath of wind ruffled it. The top
of Long's Peak rose bald and broken above. Climbing to the top of a
commanding ridge, I long watched this beautiful expanse of cloud
and could scarcely realize that it was steadily flinging multitudes of
snowflakes upon slopes and snows below. Though practically
stationary, this cloud expanse had some slight movements. These
were somewhat akin to those of a huge raft that is becalmed in a
quiet harbor. Slowly, easily, and almost imperceptibly the entire mass
slid forward along the mountains; it moved but a short distance,
paused for some minutes, then slowly slid back a trifle farther than it
had advanced. After a brief stop the entire mass, as though
anchored in the centre, started to swing in an easy, deliberate
rotation; after a few degrees of movement it paused, hesitated, then
swung with slow, heavy movement back. In addition to these
shifting horizontal motions there was a short vertical one. The entire
mass slowly sank and settled two or three hundred feet, then, with
scarcely a pause, rose easily to the level from which it sank. Only
once did it rise above this level.
During all seasons of the year there are oft-recurring periods when
the mountains sit in sunshine and all the winds are still. In days of
this kind the transcontinental passengers in glass-bottomed airships
would have a bird's-eye view of sublime scenes. The purple forests,
the embowered, peaceful parks, the drifted snows, the streams that
fold and shine through the forests,—all these combine and cover
magnificently the billowed and broken distances, while ever floating
up from below are the soft, ebbing, and intermittent songs from
white water that leaps in glory.
Though the summits of the Rocky Mountains are always cool, it is
only in rare, brief times that they fall within the frigid spell of
Farthest North and become cruelly cold. The climate among these
mountain-tops is much milder than people far away imagine.
The electrical effects that enliven and sometimes illuminate these
summits are peculiar and often highly interesting. Thunderbolts—
lightning-strokes—are rare, far less frequent than in most lowland
districts. However, when lightning does strike the heights, it appears
to have many times the force that is displayed in lowland strokes. My
conclusions concerning the infrequency of thunderbolts on these
sky-piercing peaks are drawn chiefly from my own experience. I
have stood through storms upon more than a score of Rocky
Mountain summits that were upward of fourteen thousand feet
above the tides. Only one of these peaks was struck; this was Long's
Peak, which rises to the height of 14,256 feet above the sea.
 Seventy storms I have experienced on the summit of this peak,
and during these it was struck but three times to my knowledge.
One of these strokes fell a thousand feet below the top; two struck
the same spot on the edge of the summit. The rock struck was
granite, and the effects of the strokes were similar; hundreds of
pounds of shattered rock fragments were flung horizontally afar. Out
of scores of experiences in rain-drenched passes I have record of
but two thunderbolts. Both of these were heavy. In all these
instances the thunderbolt descended at a time when the storm-cloud
was a few hundred feet above the place struck.
During the greater number of high-altitude storms the cloud is in
contact with the surface or but little removed from it. Never have I
known the lightning to strike when the clouds were close to the
surface or touching it. It is, however, common, during times of low-
dragging clouds, for the surface air to be heavily charged with
electrical fluid. This often is accompanied with strange effects.
Prominent among these is a low pulsating hum or an intermittent
buz-z-z-z, with now and then a sharp zit-zit! Sometimes
accompanying, at other times only briefly breaking in, are subdued
camp-fire cracklings and roarings. Falling snowflakes, during these
times, are occasionally briefly luminous, like fireflies, the instant they
touch the earth. Hair-pulling is the commonest effect that people
experience in these sizzling electrical storms. There is a straightening
of the hairs and apparently a sharp pull upon each. As John Muir has
it, "You are sure to be lost in wonder and praise and every hair of
your head will stand up and hum and sing like an enthusiastic
congregation." Most people take very gravely their first experience of
this kind; especially when accompanied, as it often is, with apparent
near-by bee-buzzings and a purplish roll or halo around the head.
During these times a sudden finger movement will produce a
crackling snap or spark.
On rare occasions these interesting peculiarities become irritating
and sometimes serious to one. In "A Watcher on the Heights," in
"Wild Life on the Rockies," I have described a case of this kind. A
few people suffer from a muscular cramp or spasm, and occasionally
the muscles are so tensed that breathing becomes difficult and
heart-action disturbed. I have never known an electrical storm to be
fatal. Relief from the effects of such a storm may generally be had
by lying between big stones or beneath shelving rocks. On one
occasion I saw two ladies and four gentlemen lay dignity aside and
obtain relief by jamming into a place barely large enough for two. In
my own case, activity invariably intensified these effects; and the
touching of steel or iron often had the same results. For some years
a family resided upon the slope of Mt. Teller, at an altitude of twelve
thousand feet. Commonly during storms the stove and pipe were
charged with fluid so heavily that it was a case of hands off and let
dinner wait, and sometimes spoil, until the heavens shut off the
current.
The sustaining buoyancy of the air to aerial things decreases with
altitude. In this "light" air some motor machinery is less efficient
than it is in the lowlands. It is probable that aviators will always find
the air around uplifted peaks much less serviceable than this
element upon the surface of the sea. But known and unknown
dangers in the air will be mastered, and ere long the dangers to
those who take flight through the air will be no greater than the
dangers to those who go down to the sea in ships. Flying across the
crest of the continent, above the crags and cañons, will be
enchanting, and this journey through the upper air may bring to
many the first stirring message from the rocks and templed hills.
 Rob of the Rockies

Rob of the Rockies

Hurrying out of the flood-swept mountains in northern Colorado,
in May, 1905, I came upon a shaggy black and white dog, hopelessly
fastened in an entanglement of flood-moored barbed-wire fence that
had been caught in a clump of willows. He had been carried down
with the flood and was coated with earth. Masses of mud clung here
and there to his matted hair, and his handsome tail was encased as
though in a plaster cast. He was bruised, and the barbs had given
him several cuts. One ear was slit, and a blood-clot from a cut on his
head almost closed his left eye.
Had I not chanced upon him, he probably would have perished
from hunger and slow torture. Though he must have spent twelve
hours in this miserable barbed binding, he made no outcry. The
barbs repeatedly penetrated his skin, as I untangled and uncoiled
the wires from around his neck and between his legs. As he neither
flinched nor howled, I did him the injustice to suppose that he was
almost dead. He trusted me, and as I rolled him about, taking off
that last thorny tangle, the slit ear, bloody muzzle, and muddy head
could not hide from me an expression of gratitude in his intelligent
face.
Returning from a camping-trip, and narrowly escaping drowning,
too, I was a dirty vagabond myself. When the last wire dropped from
the prisoner, he enthusiastically began to share his earth coating
with me. He leaped up and half clasped me in his fore legs, at the
same time wiping most of the mud off his head on one side of my
face. Then he darted between my legs, racing about and
occasionally leaping or flinging himself against me; each time he
leaped, he twisted as he came up so that he struck me with his
back, head, or side, and thus managed to transfer much of this
fertile coat to me. He finally ended by giving several barks, and then
racing to the near-by river for a drink and a bath. I, too, needed
another cloudburst.
Just what kinds of dogs may have made his mixed ancestry could
not be told. Occasionally I had a glimpse of a collie in him, but for all
practical purposes he was a shepherd, and he frequently exhibited
traits for which the shepherd is celebrated. I could never find out
where he came from. It may be that the flood separated him from
his master's team; he may have been washed away from one of the
flooded ranches; or he may have been, as the stage-driver later told
me, "a tramp dog that has been seen in North Park, Cheyenne, and
Greeley." Home he may have left; master he may have lost; or
tramp he may have been; but he insisted on going with me, and
after a kindly though forceful protest, I gave in and told him he
might follow.
The flood had swept all bridges away, and I was hurrying down
the Poudre, hoping to find a place to cross without being compelled
to swim. He followed, and kept close to my heels as I wound in and
out among flood débris and willow-clumps. But I did not find a place
that appeared shallow.
As it was necessary to cross, I patted my companion good-by,
thinking he would not care to go farther, and waded in. He squatted
by the water's edge and set up a howl. I stopped and explained to
him that this was very bad crossing for an injured dog, and that we
would better separate; but he only howled the more. He wanted to
go with me, but was afraid to try alone.
Returning to the bank, I found a rope in the flood wreckage, tied
this around his neck and waded in. He followed cheerfully, but swam
with effort. When about half way across, and in the water up to my
shoulders, I attached myself to a floating log lest the dog should
weaken and need help. Within sixty or seventy feet of the desired
bank we struck a stretch of swift, deep water, in which I was
compelled to let the animal go and swim for the shore. My
companion was swept down by the current, and the rope caught on
a snag, entangling my legs so that I had to cut it or drown. The
current swept poor doggie against some stranded wreckage in
midstream. On this he climbed, while I struggled on to the bank.
I called to him to come on, but he only howled. Again I called,
patted my knees, made friendly gesticulations, and did all I could
think of to encourage him. Finally, I told him that if he would only
start I would come part way and be ready to help him if he got into
trouble. But he would not start. Not desiring the task of returning for
him through the cold, strong current, and feeling in a hurry, I started
on. He howled and then cried so piteously that I went back and
towed him safely ashore.
That night some good people of the ranch house treated both of
us kindly, and in the morning they wanted to keep my companion. I
was willing that he should stay, for he would have a good place, and
I was bound for Denver, where I feared some accident would befall
him. But he growled and ran away when the man advanced to tie
him. I started on afoot and he joined me, insisting on following.
All the time he had been with me his only thought appeared to be
to stay with me. Game, dogs, horses, and people he saw and passed
with expressionless face, except two or three times when he
imagined I was in danger; then he was instantly alert for my
defense. When the stage overtook us, and stopped to let me in, he
leaped in also, and squatted by the driver with such an air of
importance that I half expected to see him take the lines and drive.
I lost him in my rush to make the train at the station. He could, of
course, have kept with me had he been without fear, or if he had
really so desired. As the train pulled out, I saw him start down-street
with an air of unconscious confidence that told of wide experience.
He was a tramp dog.
The next time I saw him was several months later, in Leadville,
some two hundred miles from where he left me. Where, in the mean
time, he may have rambled, what towns he may have visited, or
what good days or troubles he may have had, I have no means of
knowing.
I came walking into Leadville with snowshoes under my arm, from
two weeks' snowshoeing and camping on the upper slopes of the
Rockies. The ends of broken tree limbs had torn numerous right-
angled triangles in my clothes, my soft hat was unduly slouchy, and
fourteen nights' intimate association with a camp-fire, along with
only an infrequent, indifferent contact with water, had made me a
sight to behold,—for dogs, anyway. On the outskirts, one snarly cur
noticed me and barked; in a few minutes at least a dozen dogs were
closely following and making me unwelcome to their haunts. They
grew bold with time, numbers, and closer inspection of me. They
crowded unpleasantly close. Realizing that if one of them became
courageous enough to make a snap at my legs, all might follow his
example, I began to sidle out of the middle of the street, intending
to leap a fence close by and take refuge in a house.
Before I could realize it, they were snapping right and left at me,
and howling as they collided with the tail of a snowshoe which I
used as a bayonet. We were close to the fence, I trying to find time
to turn and leap over; but I was too busy, and, without assistance, it
is probable that I should have been badly bitten.
Suddenly there was something like a football mix-up at my feet,
then followed a yelping of curs, with tucked tails dashing right and
left to avoid the ferocious tackles of a shaggy black and white dog.
It was Rob, who was delighted to see me, and whom I assured that
he was most welcome.
He had been seen about Leadville for two or three months, and
several persons had bits of information concerning him. All agreed
that he had held aloof from other dogs, and that he quietly ignored
the friendly greetings of all who made advances. He was not
quarrelsome, but had nearly killed a bulldog that had attacked a boy.
On one occasion, a braying burro so irritated him that he made a
savage attack on the long-eared beast, and sent him pell-mell down
the street, braying in a most excited manner.
 The drivers of ore wagons reported that he occasionally followed
them to and from the mines up the mountainside. At one livery-
stable he was a frequent caller, and usually came in to have a drink;
but no one knew where he ate or slept. One day a little mittened girl
had left her sled, to play with him. He had responded in a most
friendly manner, and had raced, jumped, circled, and barked; at last
he had carried her slowly, proudly on his back.
I grew greatly interested in his biography, and wondered what
could have shaped his life so strangely. In what kind of a home was
his pretty puppyhood spent? Why was he so indifferent to dogs and
people, and had he left or lost a master?
Early next spring, after vainly trying to follow the trail of explorer
Pike, I struck out on a road that led me across the Wet Mountain
valley up into Sangre de Cristo Mountains. When well up into the
mountains, I saw a large dog walking slowly toward me, and at once
recognized him as Rob. Although clean and well-fed, he held his
head low and walked as though discouraged. The instant he scented
me, however, he leaped forward and greeted me with many a wag,
bark, and leap. He was one hundred miles from Leadville, and fully
three hundred miles from the flood scene on the Poudre. He faced
about and followed me up into the alpine heights, far beyond trail.
We saw a number of deer and many mountain sheep; these he
barely noticed, but a bear that we came upon he was most eager to
fight.
The second night in the mountains, near Horne's Peak, we had an
exciting time with a mountain lion. Coyotes howled during the
evening, much to the dog's annoyance. It was a cold night, and,
being without bedding, I had moved the fire and lain down upon the
warm earth. The fire was at my feet, a crag rose above my head,
and Rob was curled up against my back. A shrill, uncanny cry of the
lion roused me after less than an hour's sleep. The dog was
frightened and cuddled up close to my face. The lion was on a low
terrace in the crag, not many yards distant. Having been much in the
wilds alone and never having been attacked by lions, I had no fear
of them; but none had ever been so audacious as this one. I began
to think that perhaps it might be true that a lion would leap upon a
dog boldly at night, even though the dog lay at the feet of his
master. I kept close watch, threw stones at suspicious shadows on
the cliff terraces, and maintained a blazing fire.
Long before sunrise we started down the mountain. Both Rob and
I were hungry, and although we startled birds and rabbits, Rob paid
not the least attention to them. At noon, on Madano Pass, I lay
down for a sleep and used Rob for a pillow. This he evidently
enjoyed, for he lay still with head stretched out and one eye open.
At mid-afternoon we met a sheep-herder who was carrying a club.
I had seen this man elsewhere, and, on recognizing me as he came
up, he waved his club by the way of expressing gladness. Rob
misinterpreted this demonstration, and dragged me almost to the
frightened herder before I could make him understand that this
ragged, unwashed, club-carrying fellow had no ill wishes for me.
I had in mind to climb Sierra Blanca the following day, and hoped
to spend the night in a ranch house on the northern slope of this
great peak. Toward sundown Rob and I climbed through a pole
fence and entered the ranch house-yard. Round a corner of the
house came a boy racing on a willow switch pony. On seeing us, he
stopped, relaxed his hold on the willow and started for Rob. How
happily he ran, holding out both eager hands! The dog sprang
playfully backward, and began to dodge and bark as the boy
laughingly and repeatedly fell while trying to catch him. Just as I
entered the house, Rob was trying to climb to the top of the fence
after his new playmate.
That night Rob was agreeable with every one in the house, and
even had a romp with the cat. These people wanted to keep him,
and offered money and their best saddle-horse. I knew that with
them he would have kind treatment to the day of his death. I
wanted him, too, but I knew the weeks of mountain-exploring just
before me would be too hard for him. "Rob is a free dog," I said,
"and is, of his own choice, simply traveling with me as a companion.
I cannot sell or give him away. I like him, but, if he wants to stay, it
will be a pleasure to me to leave him."
 The next morning every one was wondering whether Rob would
go or stay. The dog had made up his mind. He watched me prepare
to leave with keenest interest, but it was evident that he had
planned to stay, and his boy friend was very happy. As I passed
through the yard, these two were playing together; at the gate I
called good-by, at which Rob paused, gave a few happy barks, and
then raced away, to try to follow his mountain boy to the top of the
old pole fence.
 Sierra Blanca

Sierra Blanca
I was rambling alone on snowshoes, doing some winter
observations in the alpine heights of the Sangre de Cristo range. It
was miles to the nearest house. There was but little snow upon the
mountains, and, for winter, the day was warm. I was thirsty, and a
spring which burst forth among the fragments of petrified wood was
more inviting than the water-bottle in my pocket. The water was
cool and clear, tasteless and, to all appearances, pure.
As I rose from drinking, a deadly, all-gone feeling overcame me.
After a few seconds of this, a violent and prolonged nausea came
on. Evidently I had discovered a mineral spring! Perhaps it was
arsenic, perhaps some other poison. Poison of some kind it must
have been, and poisonous mineral springs are not unknown.
The sickness was very like seasickness, with a severe internal pain
and a mental stimulus added. After a few minutes I partly recovered
from these effects and set off sadly for the nearest house of which I
had heard. This was eight or ten miles distant and I hoped to find it
through the guidance of a crude map which a prospector had
prepared for me. I had not before explored this mountainous
section.
 SIERRA BLANCA IN WINTER
The gulches and ridges which descended the slope at right angles
to my course gave me a rough sea which kept me stirred up. I
advanced in tottering installments; a slow, short advance would be
made on wobbly legs, then a heave-to, as pay for the advance
gained.
Now and then there was smoothness, and I took an occasional
look at severe Sierra Blanca now looming big before me. It was
mostly bare and brown with a number of icy plates and ornaments
shining in the sun.
At last in the evening light, from the top of a gigantic moraine, I
looked down upon the river and a log ranch-house nestling in a
grassy open bordered with clumps of spruces. An old lady and
gentleman with real sympathy in their faces stood in the doorway
and for a moment watched me, then hastened to help me from the
pole fence to the door.
 While giving them an incoherent account of my experience, I fell
into a stupor, and although I had evidently much to say concerning
drinking and apparently showed symptoms of too much drink, these
old people did not think me drunk. Waking from a fantastic dream I
heard, "Does he need any more sage tea?" The Western pioneers
have faith in sage tea and many ascribe to it all the life-saving, life-
extending qualities usually claimed for patent medicines. The
following morning I was able to walk about, while my slightly
bloated, bronzed face did not appear so badly. Altogether, I looked
much better than I felt.
These good old people declared that they had not seen better
days, but that they were living the simple life from choice. They
loved the peace of this isolated mountain home and the
companionship of the grand old peak. In the Central States the wife
had been a professor in a State school, while the husband had been
a State's Attorney.
The nearest neighbor was four miles downstream, and no one
lived farther up the mountain. The nearest railroad station was
seventy rough mountain-road miles away. It appeared best to hasten
to Denver, but two days in a jarring wagon to reach the railroad
seemed more than I could endure. I had not planned even to try for
the top of Colorado's highest peak in midwinter, but the way across
Sierra Blanca was shorter and probably much easier than the way
around. Across the range, directly over the shoulder of Sierra Blanca,
lay historic Fort Garland. It was only thirty miles away, and I
determined to cross the range and reach it in time for the midnight
train. On hearing this resolution the old people were at first
astonished, but after a moment they felt that they at last knew who
I was.
"You must be the Snow Man! Surely no one but he would try to do
this in winter."
They, with scores of other upland-dwellers, had heard numerous
and wild accounts of my lone, unarmed camping-trips and winter
adventures in the mountain snows.
 The misgivings of the old gentleman concerning the wisdom of my
move grew stronger when he perceived how weak I was, as we
proceeded on mule-back up the slope of Sierra Blanca. The ice
blocked us at timber-line, and in his parting handclasp I felt the
hope and fear of a father who sees his son go away into the world.
He appeared to realize that I was not only weak, but that at any
moment I might collapse. He knew the heights were steep and
stern, and that in the twenty-odd miles to Fort Garland there was
neither house nor human being to help me. Apparently he hoped
that at the last moment I would change my mind and turn back.
Up the northern side of the peak I made my way. Now and then it
was necessary to cut a few steps in the ice-plated steeps. The
shoulder of the peak across which I was to go was thirteen thousand
feet above the sea, and in making the last climb to this it was
necessary to choose between a precipitous ice-covered slope and an
extremely steep rock-slide,—more correctly a rock glacier. I picked
my way up this with the greatest caution. To start a rock avalanche
would be easy, for the loose rocks lay insecure on a slope of perilous
steepness. From time to time in resting I heard the entire mass
settling, snarling, and grinding its way with glacier slowness down
the steep.
Just beneath the shoulder the tilting steepness of this rocky débris
showed all too well that the slightest provocation would set a
grinding whirlpool of a stone river madly flowing. The expected at
last happened when a boulder upon which I lightly leaped settled
and then gave way. The rocks before made haste to get out of the
way, while those behind began readjusting themselves. The liveliest
of foot-work kept me on top of the now settling, hesitating, and
inclined-to-roll boulder. There was nothing substantial upon which to
leap.
Slowly the heavy boulder settled forward with a roll, now right,
now left, with me on top trying to avoid being tumbled into the
grinding mill hopper below. At last, on the left, a sliding mass of
crushed, macadamized rock offered a possible means of escape. Not
daring to risk thrusting a leg into this uncertain mass, I allowed
myself to fall easily backwards until my body was almost horizontal,
and then face upwards I threw myself off the boulder with all my
strength. The rock gave a great plunge, and went bounding down
the slope, sending the smaller stuff flying before at each contact
with the earth.
Though completely relaxed, and with the snowshoes on my back
acting as a buffer, the landing was something of a jolt. For a few
seconds I lay limp and spread out, and drifted slowly along with the
slow-sliding mass of macadam. When this came to rest, I rose up
and with the greatest concern for my foundation, made my way
upwards, and at last lay down to breathe and rest upon the solid
granite shoulder of Sierra Blanca.
In ten hours the midnight train would be due in Fort Garland, and
as the way was all downgrade, I hoped that my strength would hold
out till I caught it. But, turning my eyes from the descent to the
summit, I forgot the world below, and also my poison-weakened
body. Suddenly I felt and knew only the charm and the call of the
summit. There are times when Nature completely commands her
citizens. A splendid landscape, sunset clouds, or a rainbow on a
near-by mountain's slope,—by these one may be as completely
charmed and made as completely captive as were those who heard
the music of Orpheus' lyre. My youthful dream had been to scale
peak after peak, and from the earthly spires to see the scenic world
far below and far away. All this had come true, though of many trips
into the sky and cloudland, none had been up to the bold heights of
Blanca. Thinking that the poisoned water might take me from the list
of those who seek good tidings in the heights, I suddenly
determined to reach those wintry wonder-heights while yet I had the
strength. I rose from relaxation, laid down my snowshoes, and
started for the summit.
Blanca is a mountain with an enormous amount of material in it,—
enough for a score of sizable peaks. Its battered head is nearly two
thousand feet above its rugged shoulder. The sun sank slowly as I
moved along a rocky skyline ridge and at last gained the summit.
 Beyond an infinite ocean of low, broken peaks, sank the sun. It
was a wonderful sunset effect in that mountain-dotted, mountain-
walled plain, the San Luis Valley. Mist-wreathed peaks rose from the
plain, one side glowing in burning gold, the other bannered with
black shadows. The low, ragged clouds dragged slanting shadows
across the golden pale. A million slender silver threads were flung
out in a measureless horizontal fan from the far-away sun. The
sunset from the summit of Sierra Blanca was the grandest that I
have ever seen. The prismatic brilliancy played on peak and cloud,
then changed into purple, fading into misty gray, while the light of
this strong mountain day slowly vanished in the infinite silence of a
perfect mountain night.
Then came the serious business of getting down and off the rough
slope and out of the inky woods before darkness took complete
possession. After intense vigilance and effort for two hours, I
emerged from the forest-robed slope and started across the easy,
sloping plain beneath a million stars.
The night was mild and still. Slowly, across the wide brown way, I
made my course, guided by a low star that hung above Fort Garland.
My strength ran low, and, in order to sustain it, I moved slowly, lying
down and relaxing every few minutes. My mind was clear and
strangely active. With pleasure I recalled in order the experiences of
the day and the wonderful sunset with which it came triumphantly to
a close. As I followed a straight line across the cactus-padded plains,
I could not help wondering whether the Denver physicians would tell
me that going up to see the sunset was a serious blunder, or a
poison-eliminating triumph. However, the possibility of dying was a
thought that never came.
At eleven o'clock, when instinctively and positively I felt that I had
traveled far enough, I paused; but from Fort Garland neither sound
nor light came to greet me in the silent, mysterious night. I might
pass close to the low, dull adobes of this station without realizing its
presence. So confident was I that I had gone far enough that I
commenced a series of constantly enlarging semicircles, trying to
locate in the darkness the hidden fort. In the midst of these, a
coyote challenged, and a dog answered. I hastened toward the dog
and came upon a single low adobe full of Mexicans who could not
understand me. However, their soft accents awakened vivid
memories in my mind, and distinctly my strangely stimulated brain
took me back through fifteen years to the seedling orange groves in
the land of to-morrow where I had lingered and learned to speak
their tongue. An offer of five dollars for transportation to Fort
Garland in time for the midnight train sent Mexicans flying in all
directions as though I had hurled a bomb.
Two boys with an ancient, wobbling horse and buckboard landed
me at the platform as the headlight-glare of my train swept across it.
The big, good-natured conductor greeted me with "Here's the Snow
Man again,—worse starved than ever!"
 The Wealth of the Woods

The Wealth of the Woods

The ancients told many wonderful legends concerning the tree,
and claimed for it numerous extraordinary qualities. Modern
experience is finding some of these legends to be almost literal
truth, and increasing knowledge of the tree shows that it has many
of those high qualities for which it was anciently revered. Though
people no longer think of it as the Tree of Life, they are beginning to
realize that the tree is what enables our race to make a living and to
live comfortably and hopefully upon this beautiful world.
Camping among forests quickly gives one a home feeling for them
and develops an appreciation of their value. How different American
history might have been had Columbus discovered a treeless land!
The American forests have largely contributed to the development of
the country. The first settlers on the Atlantic coast felled and used
the waiting trees for home-building; they also used wood for fuel,
furniture, and fortifications. When trading-posts were established in
the wilderness the axe was as essential as the gun. From Atlantic to
Pacific the pioneers built their cabins of wood. As the country
developed, wood continued to be indispensable; it was used in
almost every industry, and to-day it has a more general use than
ever.
 SPANISH MOSS AT LAKE
CHARLES, LOUISIANA
Forests enrich us in many ways. One of these is through the
supply of wood which they produce,—which they annually produce.
Wood is one of the most useful materials used by man. Wood is the
home-making material. It gives good cheer to a million
hearthstones. How extensively it is used for tools, furniture, and
vehicles, for mine timbers and railroad development! The living
influences which forests exert, the environments which they create
and maintain, are potent to enable man best to manage and control
the earth, the air, and the water, so that these will give him the
greatest service and do him the least damage.
Forests are water-distributors, and everywhere their presence
tends to prevent both floods and extreme low water; they check
evaporation and assist drainage; they create soil; they resist sudden
changes of temperature; they break and temper the winds; they do
sanitary work by taking impurities from the air; they shelter and
furnish homes for millions of birds which destroy enormous numbers
of weed-seed and injurious insects. Lastly, and possibly most
important, forests make this earth comfortable and beautiful. Next to
the soil, they are the most useful and helpful of Nature's agencies.
Forests are moderators of climate. They heat and cool slowly.
Their slow response to change resists sudden changes, and,
consequently, they mitigate the rudeness with which sudden
changes are always accompanied. Sudden changes of temperature
are often annoying and enervating to man, and frequently do severe
damage to domestic plants and animals. They sometimes have what
may be called an explosive effect upon the life-tissues of many
plants and animals which man has domesticated and is producing for
his benefit. Many plants have been domesticated and largely so
specialized that they have been rendered less hardy. With good care,
these plants are heavy producers, but, to have from them a
premium harvest each year, they need the genial clime, the
stimulating shelter, and the constant protection which only forests
can supply. Closely allied to changes of temperature is the
movement of the air. In the sea every peninsula is a breakwater: on
land every grove is a windbreak. The effect of the violence of high
winds on fruited orchards and fields of golden grain may be
compared to the beatings of innumerable clubs. Hot waves and cold
waves come like withering breaths of flame and frost to trees and
plants. High winds may be mastered by the forest. The forest will
make even the Storm King calm, and it will also soften, temper, and
subdue the hottest or the coldest waves that blow. Forests may be
placed so as to make every field a harbor.
The air is an invisible blotter that is constantly absorbing moisture.
Its capacity to evaporate and absorb increases with rapidity of
movement. Roughly, six times as much water is evaporated from a
place that is swept by a twenty-five-mile wind as from a place in the
dead calm of the forest. The quantity of water evaporated within a
forest or in its shelter is many times less than is evaporated from the
soil in an exposed situation. This shelter and the consequent
decreased evaporation may save a crop in a dry season. During
seasons of scanty rainfall the crops often fail, probably not because
sufficient water has not fallen, but because the thirsty winds have
drawn from the soil so much moisture that the water-table in the soil
is lowered below the reach of the roots of the growing plants.
In the arid West the extra-dry winds are insatiable. In many
localities their annual capacity to absorb water is greater than the
annual precipitation of water. In "dry-farming" localities, the central
idea is to save all the water that Nature supplies, to prevent the
moisture from evaporating, to protect it from the robber winds.
Forests greatly check evaporation, and Professor L. G. Carpenter, the
celebrated irrigation engineer, says that forests are absolutely
necessary for the interests of irrigated agriculture. Considering the
many influences of the forest that are beneficial to agriculture, it
would seem as though ideal forest environments would be the best
annual assurance that the crops of the field would not fail and that
the soil would most generously respond to the seed-sower.
So well is man served in the distribution of the waters and the
management of their movements by the forests, that forests seem
almost to think. The forest is an eternal mediator between winds
and gravity in their never-ending struggle for the possession of the
waters. The forest seems to try to take the intermittent and ever-
varying rainfall and send the collected waters in slow and steady
stream back to the sea. It has marked success, and one may say it is
only to the extent the forest succeeds in doing this that the waters
become helpful to man. Possibly they may need assistance in this
work. Anyway, so great is the evaporation on the mountains of the
West that John Muir says, "Cut down the groves and the streams will
vanish." Many investigators assert that only thirty per cent of the
rainfall is returned by the rivers to the sea. Evaporation—winds—
probably carry away the greater portion of the remainder.
Afforestation has created springs and streams, not by increasing
rainfall, although the forests may do this, but by saving the water
that falls,—by checking evaporation. On some exposed watersheds
the winds carry off as much as ninety per cent of the annual
precipitation. It seems plain that wider, better forests would mean
deeper, steadier streams. Forests not only check evaporation, but
they store water and guard it from the greed of gravity. The forest
gets the water into the ground where a brake is put upon the pull of
gravity. Forest floors are covered with fluffy little rugs and pierced
with countless tree-roots. So all-absorbing is the porous, rug-covered
forest floor that most of the water that falls in the forest goes into
the ground; a small percentage may run off on the surface, but the
greater part settles into the earth and seeps slowly by subterranean
drainage, till at last it bubbles out in a spring some distance away
and below the place where the raindrops came to earth. The
underground drainage, upon which the forest insists, is much slower
and steadier than the surface drainage of a treeless place. The
tendency of the forest is to take the water of the widely separated
rainy days and dole it out daily to the streams. The forest may be
described as a large, ever-leaking reservoir.
The forest is so large a reservoir that it rarely overflows, and
seepage from it is so slow that it seldom goes dry. The presence of a
forest on a watershed tends to give the stream which rises thereon
its daily supply of water, whether it rains every day or not. By
checking evaporation, the forest swells the volume of sea-going
water in this stream, and thereby increases its water-power and
makes it more useful as a deep waterway. Forests so regulate
stream-flow that if all the watersheds were forested but few floods
would occur. Forest-destruction has allowed many a flood to form
and foam and to ruin a thousand homes. A deforested hillside may,
in a single storm, loose the hoarded soil of a thousand years.
Deforestation may result in filling a river-channel and in stopping
boats a thousand miles downstream. By bringing forests to our aid,
we may almost domesticate and control winds and waters!
One of the most important resources is soil,—the cream of the
earth, the plant-food of the world. Scientists estimate that it takes
nature ten thousand years to create a foot of soil. This heritage of
ages, though so valuable and so slowly created, may speedily be
washed away and lost. Forests help to anchor it and to hold it in
productive places. Every tree stands upon an inverted basket of
roots and rootlets. Rains may come and rains may go, but these
roots hold the soil in place. The soil of forest-covered hillsides is
reinforced and anchored with a webwork of the roots and rootlets of
the forest. Assisting in the soil-anchorage is the accumulation of
twigs and leaves, the litter rugs on the forest floor. These cover the
soil, and protect it from both wind and water erosion. The roots and
rugs not only hold soil, but add to the soil matter by catching and
holding the trash, silt, dust, and sediment that is blown or washed
into the forest. The forest also creates new soil, enriches the very
land it is using. Trash on a forest floor absorbs nitrogenous matter
from the air; every fallen leaf is a flake of a fertilizer; roots pry rocks
apart, and this sets up chemical action. Acids given off by tree-roots
dissolve even the rocks, and turn these to soil. A tree, unlike most
plants, creates more soil than it consumes. In a forest the soil is
steadily growing richer and deeper.
Birds are one of the resources of the country. They are the
protectors, the winged watchmen, of the products which man needs.
Birds are hearty eaters, and the food which they devour consists
mostly of noxious weed-seed and injurious insects. Several species
of birds feed freely upon caterpillars, moths, wood-lice, wood-borers,
and other deadly tree-enemies. Most species of birds need the forest
for shelter, a home, and a breeding-place; and, having the forest,
they multiply and fly out into the fields and orchards, and wage a
more persistent warfare even than the farmer upon the insistent and
innumerable crop-injuring weeds, and also the swarms of insatiable
crop-devouring insects. Birds work for us all the time, and board
themselves most of the time. Birds are of inestimable value to
agriculture, but many of these useful species need forest shelter. So
to lose a forest means at the same time to lose the service of these
birds.
The forest is a sanitary agent. It is constantly eliminating
impurities from the earth and the air. Trees check, sweep, and filter
from the air quantities of filthy, germ-laden dust. Their leaves absorb
the poisonous gases from the air. Roots assist in drainage, and
absorb impurities from the soil. Roots also give off acids, and these
acids, together with the acids released by the fallen, decaying
leaves, have a sterilizing effect upon the soil. Trees help to keep the
earth sweet and clean, and water which comes from a forested
watershed is likely to be pure. Many unsanitary areas have been
redeemed and rendered healthy by tree-planting.
Numerous are the products and the influences of the trees. Many
medicines for the sick-room are compounded wholly or in part from
the bark, the fruit, the juices, or the leaves of trees. Fruits and nuts
are at least the poetry of the dining-table. One may say of trees
what the French physician said of water: needed externally,
internally, and eternally! United we stand, but divided we fall, is the
history of peoples and forests. Forest-destruction seems to offer the
speediest way by which a nation may go into decline or death.
"Without forests" are two words that may be written upon the maps
of most depopulated lands and declining nations.
When one who is acquainted with both history and natural history
reads of a nation that "its forests are destroyed," he naturally
pictures the train of evils that inevitably follow,—the waste and
failure that will come without the presence of forests to prevent. He
realizes that the ultimate condition to be expected in this land is a
waste of desolate distances, arched with a gray, sad sky beneath
which a few lonely ruins stand crumbling and pathetic in the desert's
drifting sand.
The trees are our friends. As an agency for promoting and
sustaining the general welfare, the forest stands preëminent. A
nation which appreciates trees, which maintains sufficient forests,
and these in the most serviceable places, may expect to enjoy
regularly the richest of harvests; it will be a nation of homes and
land that is comfortable, full of hope, and beautiful.
 The Forest Fire

The Forest Fire

Forest fires led me to abandon the most nearly ideal journey
through the wilds I had ever embarked upon, but the conflagrations
that took me aside filled a series of my days and nights with wild,
fiery exhibitions and stirring experiences. It was early September
and I had started southward along the crest of the continental divide
of the Rocky Mountains in northern Colorado. All autumn was to be
mine and upon this alpine skyline I was to saunter southward,
possibly to the land of cactus and mirage. Not being commanded by
either the calendar or the compass, no day was to be marred by
hurrying. I was just to linger and read all the nature stories in the
heights that I could comprehend or enjoy. From my starting-place,
twelve thousand feet above the tides, miles of continental slopes
could be seen that sent their streams east and west to the two far-
off seas. With many a loitering advance, with many a glad going
back, intense days were lived. After two great weeks I climbed off
the treeless heights and went down into the woods to watch and
learn the deadly and dramatic ways of forest fires.
 A FOREST FIRE ON THE GRAND RIVER
This revolution in plans was brought about by the view from amid
the broken granite on the summit of Long's Peak. Far below and far
away the magnificent mountain distances reposed in the autumn
sunshine. The dark crags, snowy summits, light-tipped peaks, bright
lakes, purple forests traced with silver streams and groves of aspen,
—all fused and faded away in the golden haze. But these splendid
scenes were being blurred and blotted out by the smoke of a dozen
or more forest fires.
Little realizing that for six weeks I was to hesitate on fire-
threatened heights and hurry through smoke-filled forests, I took a
good look at the destruction from afar and then hastened toward the
nearest fire-front. This was a smoke-clouded blaze on the Rabbit-Ear
Range that was storming its way eastward. In a few hours it would
travel to the Grand River, which flowed southward through a
straight, mountain-walled valley that was about half a mile wide.
Along the river, occupying about half the width of the valley, was a
picturesque grassy avenue that stretched for miles between ragged
forest-edges.
There was but little wind and, hoping to see the big game that the
flames might drive into the open, I innocently took my stand in the
centre of the grassy stretch directly before the fire. This great smoky
fire-billow, as I viewed it from the heights while I was descending,
was advancing with a formidable crooked front about three miles
across. The left wing was more than a mile in advance of the active
though lagging right one. As I afterward learned, the difference in
speed of the two wings was caused chiefly by topography; the forest
conditions were similar, but the left wing had for some time been
burning up a slope while the right had traveled down one. Fire burns
swiftly up a slope, but slowly down it. Set fire simultaneously to the
top and the bottom of a forest on a steep slope and the blaze at the
bottom will overrun at least nine-tenths of the area. Flame and the
drafts that it creates sweep upward.
Upon a huge lava boulder in the grassy stretch I commanded a
view of more than a mile of the forest-edge and was close to where
a game trail came into it out of the fiery woods. On this burning
forest-border a picturesque, unplanned wild-animal parade passed
before me.
Scattered flakes of ashes were falling when a herd of elk led the
exodus of wild folk from the fire-doomed forest. They came stringing
out of the woods into the open, with both old and young going
forward without confusion and as though headed for a definite place
or pasture. They splashed through a beaver pond without stopping
and continued their way up the river. There was no show of fear, no
suggestion of retreat. They never looked back. Deer straggled out
singly and in groups. It was plain that all were fleeing from danger,
all were excitedly trying to get out of the way of something; and
they did not appear to know where they were going. Apparently
they gave more troubled attention to the roaring, the breath, and
the movements of that fiery, mysterious monster than to the seeking
of a place of permanent safety. In the grassy open, into which the
smoke was beginning to drift and hang, the deer scattered and
lingered. At each roar of the fire they turned hither and thither
excitedly to look and listen. A flock of mountain sheep, in a long,
narrow, closely pressed rank and led by an alert, aggressive bighorn,
presented a fine appearance as it raced into the open. The
admirable directness of these wild animals put them out of the
category occupied by tame, "silly sheep." Without slackening pace
they swept across the grassy valley in a straight line and vanished in
the wooded slope beyond. Now and then a coyote appeared from
somewhere and stopped for a time in the open among the deer; all
these wise little wolves were a trifle nervous, but each had himself
well in hand. Glimpses were had of two stealthy mountain lions, now
leaping, now creeping, now swiftly fleeing.
Bears were the most matter-of-fact fellows in the exodus. Each
loitered in the grass and occasionally looked toward the oncoming
danger. Their actions showed curiosity and anger, but not alarm.
Each duly took notice of the surrounding animals, and one old grizzly
even struck viciously at a snarling coyote. Two black bear cubs, true
to their nature, had a merry romp. Even these serious conditions
could not make them solemn. Each tried to prevent the other from
climbing a tree that stood alone in the open; around this tree they
clinched, cuffed, and rolled about so merrily that the frightened wild
folks were attracted and momentarily forgot their fears. The only
birds seen were some grouse that whirred and sailed by on swift,
definite wings; they were going somewhere.
With subdued and ever-varying roar the fire steadily advanced. It
constantly threw off an upcurling, unbroken cloud of heavy smoke
that hid the flames from view. Now and then a whirl of wind brought
a shower of sparks together with bits of burning bark out over the
open valley.
Just as the flames were reaching the margin of the forest a great
bank of black smoke curled forward and then appeared to fall into
the grassy open. I had just a glimpse of a few fleeing animals, then
all became hot, fiery, and dark. Red flames darted through swirling
black smoke. It was stifling. Leaping into a beaver pond, I lowered
my own sizzling temperature and that of my smoking clothes. The
air was too hot and black for breathing; so I fled, floundering
through the water, down Grand River.
A quarter of a mile took me beyond danger-line and gave me
fresh air. Here the smoke ceased to settle to the earth, but extended
in a light upcurling stratum a few yards above it. Through this smoke
the sunlight came so changed that everything around was magically
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com