Стандарт языка Си С99 TC (1113411), страница 4
Текст из файла (страница 4)
Mathematical symbols notdefined in this International Standard are to be interpreted according to ISO 31−11.3.11access〈execution-time action〉 to read or modify the value of an object2NOTE 1Where only one of these two actions is meant, ‘‘read’’ or ‘‘modify’’ is used.34NOTE 2"Modify’’ includes the case where the new value being stored is the same as the previous value.NOTE 3Expressions that are not evaluated do not access objects.3.21alignmentrequirement that objects of a particular type be located on storage boundaries withaddresses that are particular multiples of a byte address3.31argumentactual argumentactual parameter (deprecated)expression in the comma-separated list bounded by the parentheses in a function callexpression, or a sequence of preprocessing tokens in the comma-separated list boundedby the parentheses in a function-like macro invocation3.41behaviorexternal appearance or action3.4.11implementation-defined behaviorunspecified behavior where each implementation documents how the choice is made2EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bitwhen a signed integer is shifted right.3.4.21locale-specific behaviorbehavior that depends on local conventions of nationality, culture, and language that eachimplementation documents§3.4.2General3ISO/IEC 9899:TC32Committee Draft — Septermber 7, 2007WG14/N1256EXAMPLE An example of locale-specific behavior is whether the islower function returns true forcharacters other than the 26 lowercase Latin letters.3.4.31undefined behaviorbehavior, upon use of a nonportable or erroneous program construct or of erroneous data,for which this International Standard imposes no requirements2NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictableresults, to behaving during translation or program execution in a documented manner characteristic of theenvironment (with or without the issuance of a diagnostic message), to terminating a translation orexecution (with the issuance of a diagnostic message).3EXAMPLEAn example of undefined behavior is the behavior on integer overflow.3.4.41unspecified behavioruse of an unspecified value, or other behavior where this International Standard providestwo or more possibilities and imposes no further requirements on which is chosen in anyinstance2EXAMPLEevaluated.An example of unspecified behavior is the order in which the arguments to a function are3.51bitunit of data storage in the execution environment large enough to hold an object that mayhave one of two values2NOTEIt need not be possible to express the address of each individual bit of an object.3.61byteaddressable unit of data storage large enough to hold any member of the basic characterset of the execution environment23NOTE 1It is possible to express the address of each individual byte of an object uniquely.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-orderbit.3.71character〈abstract〉 member of a set of elements used for the organization, control, orrepresentation of data3.7.11charactersingle-byte character〈C〉 bit representation that fits in a byte4General§3.7.1WG14/N1256Committee Draft — Septermber 7, 2007ISO/IEC 9899:TC33.7.21multibyte charactersequence of one or more bytes representing a member of the extended character set ofeither the source or the execution environment2NOTEThe extended character set is a superset of the basic character set.3.7.31wide characterbit representation that fits in an object of type wchar_t, capable of representing anycharacter in the current locale3.81constraintrestriction, either syntactic or semantic, by which the exposition of language elements isto be interpreted3.91correctly rounded resultrepresentation in the result format that is nearest in value, subject to the current roundingmode, to what the result would be given unlimited range and precision3.101diagnostic messagemessage belonging to an implementation-defined subset of the implementation’s messageoutput3.111forward referencereference to a later subclause of this International Standard that contains additionalinformation relevant to this subclause3.121implementationparticular set of software, running in a particular translation environment under particularcontrol options, that performs translation of programs for, and supports execution offunctions in, a particular execution environment3.131implementation limitrestriction imposed upon programs by the implementation3.141objectregion of data storage in the execution environment, the contents of which can representvalues§3.14General5ISO/IEC 9899:TC32NOTECommittee Draft — Septermber 7, 2007WG14/N1256When referenced, an object may be interpreted as having a particular type; see 6.3.2.1.3.151parameterformal parameterformal argument (deprecated)object declared as part of a function declaration or definition that acquires a value onentry to the function, or an identifier from the comma-separated list bounded by theparentheses immediately following the macro name in a function-like macro definition3.161recommended practicespecification that is strongly recommended as being in keeping with the intent of thestandard, but that may be impractical for some implementations3.171valueprecise meaning of the contents of an object when interpreted as having a specific type3.17.11implementation-defined valueunspecified value where each implementation documents how the choice is made3.17.21indeterminate valueeither an unspecified value or a trap representation3.17.31unspecified valuevalid value of the relevant type where this International Standard imposes norequirements on which value is chosen in any instance2NOTEAn unspecified value cannot be a trap representation.3.181 xceiling of x: the least integer greater than or equal to x2EXAMPLE2.
4 is 3, −2. 4 is −2.3.191 xfloor of x: the greatest integer less than or equal to x2EXAMPLE62. 4 is 2, −2. 4 is −3.General§3.19WG14/N1256Committee Draft — Septermber 7, 2007ISO/IEC 9899:TC34. Conformance1In this International Standard, ‘‘shall’’ is to be interpreted as a requirement on animplementation or on a program; conversely, ‘‘shall not’’ is to be interpreted as aprohibition.2If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated, thebehavior is undefined.
Undefined behavior is otherwise indicated in this InternationalStandard by the words ‘‘undefined behavior’’ or by the omission of any explicit definitionof behavior. There is no difference in emphasis among these three; they all describe‘‘behavior that is undefined’’.3A program that is correct in all other aspects, operating on correct data, containingunspecified behavior shall be a correct program and act in accordance with 5.1.2.3.4The implementation shall not successfully translate a preprocessing translation unitcontaining a #error preprocessing directive unless it is part of a group skipped byconditional inclusion.5A strictly conforming program shall use only those features of the language and libraryspecified in this International Standard.2) It shall not produce output dependent on anyunspecified, undefined, or implementation-defined behavior, and shall not exceed anyminimum implementation limit.6The two forms of conforming implementation are hosted and freestanding.
A conforminghosted implementation shall accept any strictly conforming program. A conformingfreestanding implementation shall accept any strictly conforming program that does notuse complex types and 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>, <stdarg.h>, <stdbool.h>, <stddef.h>, and<stdint.h>. A conforming implementation may have extensions (including additionallibrary functions), provided they do not alter the behavior of any strictly conformingprogram.3)2)A strictly conforming program can use conditional features (such as those in annex F) provided theuse is guarded by a #ifdef directive with the appropriate macro.
For example:#ifdef _ _STDC_IEC_559_ _ /* FE_UPWARD defined *//* ... */fesetround(FE_UPWARD);/* ... */#endif3)§4This implies that a conforming implementation reserves no identifiers other than those explicitlyreserved in this International Standard.General7ISO/IEC 9899:TC3Committee Draft — Septermber 7, 2007WG14/N12567A conforming program is one that is acceptable to a conforming implementation.4)8An 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 <float.h> (7.7), alternative spellings <iso646.h>(7.9), sizes of integer types <limits.h> (7.10), variable arguments <stdarg.h>(7.15), boolean type and values <stdbool.h> (7.16), common definitions<stddef.h> (7.17), integer types <stdint.h> (7.18).4)8Strictly conforming programs are intended to be maximally portable among conformingimplementations.
Conforming programs may depend upon nonportable features of a conformingimplementation.General§4WG14/N1256Committee Draft — Septermber 7, 2007ISO/IEC 9899:TC35. Environment1An implementation translates C source files and executes C programs in two dataprocessing-system environments, which will be called the translation environment andthe execution environment in this International Standard. Their characteristics define andconstrain the results of executing conforming C programs constructed according to thesyntactic and semantic rules for conforming implementations.Forward references: In this clause, only a few of many possible forward referenceshave been noted.5.1 Conceptual models5.1.1 Translation environment5.1.1.1 Program structure1A C program need not all be translated at the same time.
The text of the program is keptin units called source files, (or preprocessing files) in this International Standard. Asource file together with all the headers and source files included via the preprocessingdirective #include is known as a preprocessing translation unit. After preprocessing, apreprocessing translation unit is called a translation unit. Previously translated translationunits may be preserved individually or in libraries. The separate translation units of aprogram communicate by (for example) calls to functions whose identifiers have externallinkage, manipulation of objects whose identifiers have external linkage, or manipulationof data files.
Translation units may be separately translated and then later linked toproduce an executable program.Forward references: linkages of identifiers (6.2.2), external definitions (6.9),preprocessing directives (6.10).5.1.1.2 Translation phases1The precedence among the syntax rules of translation is specified by the followingphases.5)1.5)Physical source file multibyte characters are mapped, in an implementationdefined manner, to the source character set (introducing new-line characters forend-of-line indicators) if necessary. Trigraph sequences are replaced bycorresponding single-character internal representations.Implementations shall behave as if these separate phases occur, even though many are typically foldedtogether in practice. Source files, translation units, and translated translation units need notnecessarily be stored as files, nor need there be any one-to-one correspondence between these entitiesand any external representation.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
