C语言国际标准详解与应用

需积分: 0 200 浏览量更新于2024-07-26 收藏 1.42MB PDF 举报

ANSI C Standard是C语言的一种正式标准，由国际标准化组织（ISO）和国际电工委员会（IEC）联合制定，旨在规范C语言的形式和解释，提高程序的可移植性、可靠性和可维护性，以及在不同计算系统上的高效执行。正文: ANSI C，全称为美国国家标准学会（American National Standards Institute）制定的C语言标准，后来被ISO采纳成为ISO/IEC 9899标准，通常被称为C99或C11，代表了C语言的两个主要版本。这个标准详尽地定义了C语言的语法、语义以及库函数，确保编写的C代码能在不同的硬件和操作系统上保持一致的行为。标准的核心内容包括以下几个方面： 1. **语法**：ANSI C标准定义了C语言的词汇法和句法，包括关键字、标识符、运算符、控制结构等。例如，它规定了变量声明、循环结构、条件判断、函数定义和调用等的基本规则。 2. **类型系统**：C语言有丰富的类型系统，包括基本类型（如int、char、float、double等）、枚举类型、指针类型和结构体等复合类型。标准详细规定了这些类型的大小、精度以及它们之间的转换规则。 3. **内存管理**：标准描述了C语言中的内存模型，包括静态存储区、栈、堆以及自动变量的生命周期。它还规定了如何通过malloc和free等函数进行动态内存分配和释放。 4. **预处理器**：C语言的预处理器（#include、#define等）在标准中也有详细的规定，允许程序员进行宏定义、条件编译等操作。 5. **标准库**：ANSI C标准包含了一个核心库，提供了一系列函数，如输入输出操作（stdio.h）、数学运算（math.h）、字符串处理（string.h）等。这些函数确保了跨平台的兼容性。 6. **错误处理**：标准定义了错误处理机制，如errno变量和setjmp/longjmp等，帮助开发者处理运行时错误和异常情况。 7. **可移植性**：考虑到C语言的广泛使用，标准特别强调了代码的可移植性。附录中列出了影响可移植性的因素，如数据类型的最大值、浮点数的精度差异等，帮助程序员编写更健壮的代码。 8. **程序的连接和链接**：标准也涵盖了编译后的对象文件如何组合成可执行程序的规则，包括外部链接、符号解析和重定位等过程。 9. **附录和 annexes**：除了主体部分，ANSI C标准还包括多个附录，总结了语言和库的关键特性，列举了对程序可移植性有影响的因素，并给出了某些特性的实现建议。尽管ANSI C标准是为有经验的C语言程序员和翻译系统实现者设计的，但标准文档本身并不打算作为C语言教程使用。它为C语言的实现和使用提供了权威的参考，对于深入理解C语言的底层机制和正确编写可移植的代码至关重要。

4 Committee Draft — August 3, 1998 WG14/N843

3.11

1 implementation-deﬁned behavior

unspeciﬁed behavior where each implementation documents how the choice is made

EXAMPLE An example of implementation-deﬁned behavior is the propagation of the high-order bit

when a signed integer is shifted right.

3.12

1 implementation limits

restrictions imposed upon programs by the implementation

3.13

1 locale-speciﬁc behavior

behavior that depends on local conventions of nationality, culture, and language that each

implementation documents

EXAMPLE An example of locale-speciﬁc behavior is whether the islower function returns true for

characters other than the 26 lowercase Latin letters.

3.14

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

NOTE The extended character set is a superset of the basic character set.

3.15

1 object

region of data storage in the execution environment, the contents of which can represent

lues

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 deﬁnition that acquires a value on

entry to the function, or an identiﬁer from the comma-separated list bounded by the

parentheses immediately following the macro name in a function-like macro deﬁnition

3.17

1 recommended practice

speciﬁcations that are strongly recommended as being in keeping with the intent of the

standard, but that may be impractical for some implementations

3.11 General 3.17

WG14/N843 Committee Draft — August 3, 1998 5

3.18

1 undeﬁned behavior

behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or

of indeterminately valued objects, for which this International Standard imposes no

requirements

NOTE Possible undeﬁned 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).

EXAMPLE An example of undeﬁned behavior is the behavior on integer overﬂow.

3.19

1 unspeciﬁed behavior

behavior where this International Standard provides two or more possibilities and

imposes no requirements on which is chosen in any instance

EXAMPLE An example of unspeciﬁed behavior is the order in which the arguments to a function are

evaluated.

Forward references: bitwise shift operators (6.5.7), expressions (6.5), function calls

(6.5.2.2), the islower function (7.4.1.6), localization (7.11).

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 is violated, the

behavior is undeﬁned. Undeﬁned behavior is otherwise indicated in this International

Standard by the words ‘‘undeﬁned behavior’’ or by the omission of any explicit deﬁnition

of behavior. There is no difference in emphasis among these three; they all describe

‘‘behavior that is undeﬁned’’.

3 A program that is correct in all other aspects, operating on correct data, containing

unspeciﬁed behavior shall be a correct program and act in accordance with 5.1.2.3.

The implementation shall not successfully translate a preprocessing translation unit

containing a #error preprocessing directive u

nless it is part of a group skipped by

conditional inclusion.

5Astrictly conforming program shall use only those features of the language and library

speciﬁed in this International Standard.

It shall not produce output dependent on any

unspeciﬁed, undeﬁned, or implementation-deﬁned behavior, and shall not exceed any

minimum implementation limit.

3.17 General 4

WG14/N843 Committee Draft — August 3, 1998 7

5. Environment

1 An implementation translates C source ﬁles 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 deﬁne 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 ﬁles, (or preprocessing ﬁles) in this International Standard.

source ﬁle together with all the headers and source ﬁles 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 identiﬁers have external

linkage, manipulation of objects whose identiﬁers have external linkage, or manipulation

of data ﬁles. Translation units may be separately translated and then later linked to

produce an executable program.

Forward references: conditional inclusion (6.10.1), linkages of identiﬁers (6.2.2),

source ﬁle inclusion (6.10.2), external deﬁnitions (6.9), preprocessing directives (6.10).

5.1.1.2 Translation phases

1 The precedence among the syntax rules of translation is speciﬁed by the following

phases.

1. Physical source ﬁle multibyte characters are mapped to the source character set

(introducing new-line characters for end-of-line indicators) if necessary. T

rigraph

sequences are replaced by corresponding single-character internal representations.

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.

If,

as a result, a character sequence that matches the syntax of a unive

rsal character

name is produced, the behavior is undeﬁned. Only the last backslash on any

physical source line shall be eligible for being part of such a splice. A source ﬁle

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.

5) Implementations shall behave as if these separate phases occur, even though many are typically folded

together in practice.

5 Environment 5.1.1.2

8 Committee Draft — August 3, 1998 WG14/N843

3. The source ﬁle is decomposed into preprocessing tokens

and sequences of

white-space characters (including comments). A source ﬁle 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-deﬁned.

4. Preprocessing directives are executed, macro invocations are e

xpanded, 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 undeﬁned. A #include preprocessing

directive causes the named header or source ﬁle to be processed from phase 1

through phase 4, recursively. All preprocessing directives are then deleted.

5. Each source character set member, escape sequence, and universal character name

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-deﬁned member.

6. Adjacent string literal tokens are concatenated.

7. White-space characters separating tokens are no longer signiﬁcant. 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 deﬁned 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 deﬁnitions (6.9).

5.1.1.3 Diagnostics

1 A conforming implementation shall produce at least one diagnostic message (identiﬁed in

an implementation-deﬁned 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

speciﬁed as undeﬁned or implementation-deﬁned. Diagnostic messages need not be

produced in other circumstances.

EXAMPLE An implementation shall issue a diagnostic for the translation unit:

6) As described in 6.4, the process of dividing a source ﬁle’s characters into preprocessing tokens is

context-dependent. For example, see the handling of < within a #include preprocessing directive.

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

5.1.1.2 Environment 5.1.1.3

剩余549页未读，继续阅读

wilber1202

粉丝: 6
资源: 1

C语言国际标准详解与应用

ANSI C标准与雷电C语言源码实战项目解析

ANSI C标准文件详解

ISO/IEC 9899:1999 - ANSI C语言标准详解

ansi c standard

Ansi C standard

ANSI C standard file

C语言标准规范：编程语法与执行库详解

C语言标准草案解析： ANSI C99

基于Flask，mysql slope one的图书推荐系统全部资料+详细文档.zip

舰艇2 glb模型文件，航空母舰glb模型（亲测可用） 效果图见描述

最新资源

舰艇2 glb模型文件，航空母舰glb模型（亲测可用）效果图见描述