美国国家标准C语言详解及其 rationale

5星 · 超过95%的资源需积分: 9 125 浏览量更新于2024-07-25 收藏 523KB PDF 举报

"ANSI+C+Rationale.pdf" 是一份关于标准C语言的深入阐述文档，它详细讨论了美国国家标准信息系统的编程语言C的相关背景和理由。文档的主要目标是为C语言提供一个清晰的解释和规范，以便于程序员理解和遵循，确保代码的一致性和可移植性。在文章的开头，"Introduction"部分（第1章）首先定义了文档的目的，可能涉及为什么需要一个统一的标准来规范C语言，以及该标准如何填补当时编程环境中的空白。章节1.1可能涵盖了C语言在当时的软件开发中的重要性，以及ANSI（American National Standards Institute）制定此标准的动机，可能是为了促进不同系统间程序的兼容性和互操作性。接着，章节1.2讨论了文档的范围，包括它所覆盖的C语言特性和语法细节，以及可能排除或不包含的特定主题。这部分可能会提到与其他编程语言的对比分析，以及标准对C语言历史版本的继承与扩展。章节1.3列出了文档引用的其他重要参考资料，这些资料可能是先前的C语言标准、相关的技术报告或是其他权威的技术文献，为读者提供了进一步研究的基础。章节1.4概述了文档的结构，可能包括章节划分、逻辑流程和各部分之间的关系，帮助读者更好地理解内容组织。在章节1.5中，文档列举了基础文档，这些可能是ANSI制定C标准时参考的官方文档或者历史标准，有助于理解标准的来源和演变过程。定义术语（1.6）这部分对文档中使用的专业术语进行了精确的定义，确保读者在阅读过程中不会因为词汇差异而产生误解。 1.7部分讨论了合规性，可能包括如何检验代码是否符合ANSI C标准，以及标准对于不同平台和工具链的适用性。最后，章节1.8探讨了未来的发展方向，可能会提到标准可能的更新、新功能的添加，以及如何应对技术进步带来的挑战。环境部分（2.1）重点关注了C语言在各种概念模型中的应用，比如面向对象编程、模块化设计，以及C语言如何适应不同的操作系统和硬件平台，如UNIX、DEC的PDP-11等，同时提及了POSIX标准，它是C语言在Unix-like系统中的实现规范。 "ANSI+C+Rationale.pdf"文档旨在为C语言程序员提供一个详尽的指南，帮助他们理解并遵循ANSI C标准，确保其代码质量和跨平台兼容性。

Section 2. ENVIRONMENT

upon C, the prepro cessing commands accreted over time, with little central direction,

and with even less precision in their do cumentation. This evolution has resulted in

avariety of lo cal features, each with its ardent adherents: the Base Do cument oers

little clear basis for choosing one over the other.

The consensus of the Committee is that prepro cessing should b e simple and

overt

, that it should sacrice p ower for clarity.For instance, the macro invocation

f(a, b)

should assuredly havetwo actual arguments, even if

expands to

c, d

;

and the formal denition of

must call for exactly two arguments. Above all,

the preprocessing sub-language should be sp ecied precisely enough to minimize or

eliminate dialect formation.

To clarify the nature of prepro cessing, the translation from source text to tokens

is sp elled out as a number of separate phases. The separate phases need not actually

be present in the translator, but the net eect must be

as if

they were. The phases

need not b e performed in a separate prepro cessor, although the denition certainly

permits this common practice. Since the preprocessor need not knowanything

about the specic prop erties of the target, a machine-independent implementation

is permissible.

The Committee deemed that it was outside the scop e of its mandate to require

the output of the prepro cessing phases b e available as a separate translator output

le.

The

phases of translation

are sp elled out to resolve the numerous questions

raised ab out the precedence of dierent parses. Can a

#define

begin a comment?

(No.) Is backslash/new-line p ermitted within a trigraph? (No.) Must a comment

be contained within one

#include

le? (Yes.) And so on. The Rationale section

on preprocessing (

3.8) discusses the reasons for many of the particular decisions

which shaped the specication of the phases of translation.

A backslash immediately b efore a new-line has long been used to continue string

literals, as well as prepro cessing command lines. In the interest of easing machine

generation of C, and of transporting code to machines with restrictivephysical

line lengths, the Committee generalized this mechanism to permit

any

token to b e

continued byinterp osing a backslash/new-line sequence.

2.1.1.3 Diagnostics

By mandating some form of diagnostic message for any program containing a syntax

error or constraint violation, the Standard p erforms two important services. First, it

gives teeth to the concept of

erroneous program

, since a conforming implementation

must distinguish such a program from a valid one. Second, it severely constrains

the nature of extensions p ermissible to a conforming implementation.

The Standard says nothing about the nature of the diagnostic message, which

could simply b e \

syntax error

", with no hint of where the error o ccurs. (An

implementation must, of course, describ e what translator output constitutes a di-

agnostic message, so that the user can recognize it as such.) The Committee ulti-

2.1. Conceptual mo dels

mately decided that any diagnostic activitybeyond this level is an issue of

quality of

implementation

, and that market forces would encourage more useful diagnostics.

Nevertheless, the Committee felt that at least some signicant class of errors must

be diagnosed, and the class specied should b e recognizable by all translators.

The Standard do es not forbid extensions, but such extensions must not inval-

idate strictly conforming programs. The translator must diagnose the use of such

extensions, or allow them to b e disabled as discussed in (Rationale)

1.7. Other-

wise, extensions to a conforming C implementation lie in such realms as dening

semantics for syntax to which no semantics is ascrib ed by the Standard, or giving

meaning to

undenedbehavior

2.1.2 Execution environments

The denition of

program startup

in the Standard is designed to p ermit initialization

of static storage by executable code, as well as by data translated into the program

image.

2.1.2.1 Freestanding environment

As little as possible is said about freestanding environments, since little is served by

constraining them.

2.1.2.2 Hosted environment

The properties required of a hosted environment are spelled out in a fair amountof

detail in order to give programmers a reasonable chance of writing programs which

are portable among suchenvironments.

The behavior of the arguments to

main

, and of the interactionof

exit

main

and

atexit

(see

4.10.4.2) has been co died to curb some unwanted varietyinthe

representation of

argv

strings, and in the meaning of values returned by

main

The sp ecication of

argc

and

argv

as arguments to

main

recognizes extensive

prior practice.

argv[argc]

is required to be a null pointer to provide a redundant

check for the end of the list, also on the basis of common practice.

main

is the only function that may p ortably b e declared either with zero or two

arguments. (The number of arguments must ordinarily match exactly b etween invo-

cation and denition.) This sp ecial case simply recognizes the widespread practice

of leaving o the arguments to

main

when the program does not access the program

argument strings. While many implementations support more than two arguments

main,

such practice is neither blessed nor forbidden by the Standard; a program

that denes

main

with three arguments is not

strictly conforming

. (See Standard

Append ix F.5.1.)

Command line I/O redirection is not mandated by the Standard; this was deemed

to be a feature of the underlying operating system rather than the C language.

RATIONALE

Section 2. ENVIRONMENT

2.1.2.3 Program execution

Because C expressions can contain side eects, issues of

sequencing

are important

in expression evaluation. (See

3.3.) Most op erators imp ose no sequencing require-

ments, but a few operators impose

sequencepoints

upon the evaluation: comma,

logical-AND, logical-OR, and conditional. For example, in the expression

(i=1,

a[i] = 0)

the side eect (alteration to storage) sp ecied by

i=1

must b e com-

pleted b efore the expression

a[i] = 0

is evaluated.

Other sequence p oints are imp osed by statement execution and completion of

evaluation of a

ful l expression

. (See

3.6). Thus in

fn(++a)

, the incrementation of

must be completed before

is called. In

i = 1; a[i] = 0;

the side-eect of

i=1

must b e complete before

a[i] = 0

is evaluated.

The notion of

agreement

has to do with the relationship b etween the

abstract

machine

dening the semantics and an actual implementation. An

agreement point

for some ob ject or class of ob jects is a sequence point at which the value of the

ob ject(s) in the real implementation must agree with the value prescribed by the

abstract semantics.

For example, compilers that hold variables in registers can sometimes drastically

reduce execution times. In a lo op like

sum=0;

for (i = 0; i < N; ++i)

sum += a[i];

both

sum

and

might be protably kept in registers during the execution of the

loop. Thus, the actual memory ob jects designated by

sum

and

would not change

state during the loop.

Such b ehavior is, of course, too loose for hardware-oriented applications suchas

device drivers and memory-mapp ed I/O. The following loop lo oks almost identical

to the previous example, but the specication of

volatile

ensures that each assign-

mentto

*ttyport

takes place in the same sequence, and with the same values, as

the (hypothetical) abstract machine would have done.

volatile short *ttyport;

/* ... */

for (i = 0; i < N; ++i)

*ttyport = a[i];

Another common optimization is to pre-compute common subexpressions. In

this loop:

volatile short *ttyport;

short mask1, mask2;

/* ... */

for (i = 0; i < N; ++i)

*ttyport = a[i] & mask1 & mask2;

2.2. Environmental considerations

evaluation of the subexpression

mask1 & mask2

could b e p erformed prior to the

loop in the real implementation, assuming that neither

mask1

nor

mask2

appear as

an op erand of the address-of (

) operator anywhere in the function. In the abstract

machine, of course, this sub expression is re-evaluated at each lo op iteration, but

the real implementation is not required to mimic this repetitiveness, because the

variables

mask1

and

mask2

are not

volatile

and the same results are obtained

either way.

The previous example shows that a subexpression can be pre-computed in the

real implementation. A question sometimes asked regarding optimization is, \Is

the rearrangement still conforming if the pre-computed expression might raise a

signal (such as division by zero)?" Fortunately for optimizers, the answer is \Yes,"

because anyevaluation that raises a computational signal has fallen into an

undened

behavior

(

3.3), for whichany action is allowable.

Behavior is described in terms of an

abstract machine

to underscore, once again,

that the Standard mandates results

as if

certain mechanisms are used, without

requiring those actual mechanisms in the implementation. The Standard species

agreement p oints at which the value of an ob ject or class of ob jects in an implemen-

tation must agree with the value ascrib ed by the abstract semantics.

Appendix B to the Standard lists the sequence p oints sp ecied in the b ody of

the Standard.

The class of

interactive devices

is intended to include at least asynchronous ter-

minals, or paired display screens and keyboards. An implementation may extend the

denition to include other input and output devices, or even network inter-program

connections, provided they obey the Standard's characterization of interactivity.

2.2 Environmental considerations

2.2.1 Character sets

The Committee ultimately came to remarkable unanimity on the sub ject of character

set requirements. There was strong sentiment that C should not be tied to ASCI I,

despite its heritage and despite the precedent of Ada b eing dened in terms of ASCII.

Rather, an implementation is required to provide a unique character code for each

of the printable graphics used by C, and for each of the control co des representable

by an escap e sequence. (No particular graphic representation for anycharacter is

prescribed | thus the common Japanese practice of using the glyph Y= for the C

character

\

is perfectly legitimate.) Translation and execution environments may

have dierentcharacter sets, but eachmust meet this requirement in its own way.

The goal is to ensure that a conforming implementation can translate a C translator

written in C.

For this reason, and economy of description, source co de is described

as if

undergoes the same translation as text that is input by the standard library I/O rou-

tines: each line is terminated by some new-line character, regardless of its external

representation.

RATIONALE

Section 2. ENVIRONMENT

2.2.1.1 Trigraph sequences

Trigraph sequences

have been introduced as alternate spellings of some characters

to allow the implementation of C in character sets which do not provide a sucient

number of non-alphabetic graphics.

Implementations are required to support these alternate spellings, even if the

character set in use is ASCII, in order to allow transp ortation of code from systems

whichmust use the trigraphs.

The Committee faced a serious problem in trying to dene a character set for C.

Not all of the character sets in general use have the rightnumberofcharacters, nor do

they supp ort the graphical symbols that C users expect to see. For instance, many

character sets for languages other than English resemble ASCII except that co des

used for graphic characters in ASCII are instead used for extra alphab etic characters

or diacritical marks. C relies upon a richer set of graphic characters than most other

programming languages, so the representation of programs in character sets other

than ASCI I is a greater problem than for most other programming languages.

The International Standards Organization (ISO) uses three technical terms to

describe character sets:

repertoire

col lating sequence

, and

codeset

. The

repertoire

the set of distinct printable characters. The term abstracts the notion of printable

character from any particular representation; the glyphs R,

, and

all

represent the same element of the rep ertoire, upp er-case-R, which is distinct from

lower-case-r. Having decided on the repertoire to b e used (C needs a rep ertoire of

96 characters), one can then picka

col lating sequence

which corresp onds to the in-

ternal representation in a computer. The repertoire and collating sequence together

form the

codeset

What is needed for C is to determine the necessary rep ertoire, ignore the collating

sequence altogether (it is of no importance to the language), and then nd ways of

expressing the rep ertoire in a way that should give no problems with currently

popular codesets.

C derived its repertoire from the ASCII codeset. Unfortunately the ASCII rep er-

toire is not a subset of all other commonly used character sets, and widespread

practice in Europ e is not to implement all of ASCI I either, but use some parts of

its collating sequence for sp ecial national characters.

The solution is an internationally agreed-upon rep ertoire, in terms of which

an international representation of C can b e dened. The ISO has dened sucha

standard: ISO 646 describ es an

invariant subset

of ASCII.

The characters in the ASCII repertoire used by C and absent from the ISO 646

repertoire are:

#[]{}\|~^

Given this rep ertoire, the Committee faced the problem of dening representations

for the absentcharacters. The obvious idea of dening two-character escape se-

quences fails because C uses all the characters which

are

in the ISO 646 rep ertoire:

剩余124页未读，继续阅读

o0TT0o

粉丝: 0
资源: 14

美国国家标准C语言详解及其 rationale

C语言标准全集(c89(X3.159)/c99/C99Rationale)

ANSI C rationale

ANSI C Rationale

C语言中的Rationale for Excessive Type Casting是什么

algorithmic trading: winning strategies and their rationale pdf

算法的model rationale设计什么意思

客户获得收据的describe, rationale, basic flow, alternative flow, precondition, post-condition

步入式客人预订房间的rationale, basic flow, alternative flow, precondition, post-condition

客户打电话预订房间的rationale, basic flow, alternative flow, precondition, post-condition

android权限申请修改弹窗内容

最新资源