Let Us C

Posted on Sat 28 May 2016 in Learning

LET US C

The latest C is C11.

Function called at startup is main(). Can be defined by either no parameters or the following parameters int main(int argc, char *argv[]) Return type for main should be int. argc cannot be negative.

Terms

  1. access 〈execution-time action〉 to read or modify the value of an object. Either read OR modify, strictly.

  2. alignment requirement that objects of a particular type be located on storage boundaries with addresses that are particular multiples of a byte address

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:201x Committee Draft — April 12, 2011 N1570 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 implementationdefined. 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 N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x 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:201x Committee Draft — April 12, 2011 N1570 2 NOTE 1 Tw o 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 runtimeconstraints for a library function are not violated by the program; see K.3.1.4. 6 General §3.18 N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x 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 ISO/IEC 9899:201x Committee Draft — April 12, 2011 N1570 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 runtimeconstraint 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 , , , , , , , , and . 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 N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x 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 implementationdefined and locale-specific characteristics and all extensions. Forward references: conditional inclusion (6.10.1), error directive (6.10.5), characteristics of floating types (7.7), alternative spellings (7.9), sizes of integer types (7.10), alignment (7.15), variable arguments (7.16), boolean type and values (7.18), common definitions (7.19), integer types (7.20), (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 ISO/IEC 9899:201x Committee Draft — April 12, 2011 N1570 5. Environment 1 An implementation translates C source files and executes C programs in two dataprocessing-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 implementationdefined 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 N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x 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 implementationdefined 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.