ISO/IEC TR 10176:2003 情報技術—プログラミング言語標準の準備のためのガイドライン | ページ 6

3.3.1

errors

The incorrect program constructs which are statically determinable solely from inspection of the program text, without execution, and from knowledge of the language syntax. A fatal error is one from which recovery is not possible, i.e. it is not possible to proceed to (or continue with) program execution. A non-fatal error is one from which such recovery is possible.

Note 1 to entry: A fatal error may not necessarily preclude the processor from continuing to process the program, in ways which do not involve program execution (for example, further static analysis of the program text).

3.3.2

exceptions

The instances of incorrect program functioning which in general are determinable only dynamically, through execution of the program. A fatal exception is one from which recovery is not possible, i.e. it is not possible to continue with (or to proceed to) program execution. A non-fatal exception is one from which recovery is possible.

Note 1 to entry: In case of doubt, “possible” within this section should be interpreted as “possible without violating definitions within or requirements of the standard”. For example, the hardware element of a language processor may have the technical capability of continuing program execution after division by zero, but in terms of a language standard which defines division by zero as a fatal exception, the consequences of such continued execution would not be meaningful.

Note 2 to entry: See also 3.3.4.

3.3.3

conditions

Occurrences during execution of the program which cause an interruption of normal processing when detected. A condition may be an exception, or may be some language-defined or user-defined occurrence, depending on the language.

Note 1 to entry: For example, reaching end-of-file on input may always be an exception in one language, may always be a condition in another, while in a third it may be a condition if action to be taken on detection is specified in the program, but an exception if its occurrence is not anticipated.

3.3.4

relationship to other terminology

3.5.1

secondary standards

In this Technical Report, a secondary standard is one which requires strict conformity with another (“primary”) standard - or possibly more than one primary standard - but places further requirements on conforming products (e.g. in the context of this Technical Report, on language processors or programs).

3.5.2

incremental standards

In this Technical Report, an incremental standard adds to an existing standard without modifying its content. Its purpose is to supplement the coverage of the existing standard within its scope (e.g. language definition) rather than (as with a secondary standard, see 3.5.1) to add further requirements upon products conforming with an existing standard which are outside that scope. It is recognized that in some cases it might be desirable to produce a standard additional to an existing one which was both “incremental” (in terms of language functionality) and “secondary” (in terms of other requirements upon products).

3.5.3

supplementary standards

In this Technical Report, a supplementary standard adds functionality to an existing standard without extending its range of syntactic constructs; such as by the binding of a language to a specific set of functions. Supplementary standards are expected to be expressed in terms of the base language which they supplement, but do not replace any elements of the primary standard.

3.6.1

octet

An ordered sequence of eight bits considered as a unit.

3.6.2

byte

An individually addressable unit of data storage used to store a character, portion of a character or other data.

3.6.3

character

A member of a set of elements used for the organization, control, or representation of data.

Note 1 to entry: The definition above is that from the standard developed by ISO/IEC JTC 1/SC2. This ensures that the term “character” used in this TR is consistent with the coded character set standard. The composite sequence of ISO/IEC 10646 is not considered as a character. Each element of a composite sequence (as it is in ISO/IEC 10646) is considered as a “character” in this TR.

3.6.4

combining character

A member of an identified subset of the coded character set of ISO/IEC 10646 intended for combination with the preceding non-combining graphic character, or with a sequence of combining characters preceded by a non-combining character.

3.6.5

composite sequence

A sequence of graphic characters consisting of a non-combining character followed by one or more combining characters.

Note 1 to entry: A graphic symbol for a composite sequence generally consists of the combination of the graphic symbols of each character in the sequence.

Note 2 to entry: A composite sequence is not a character and therefore is not a member of the repertoire of ISO/IEC 10646.

3.6.7

coded character

A character together with its coded representation.

3.6.8

basic character set

A character set that is common across every execution environment of a programming language, e.g. The invariant set of ISO/IEC 646.

3.6.9

extended character set

A character set that is used in an execution environment, e.g. ISO/IEC 10646-1. In most cases, the repertoire of the extended character set is larger than the basic character set.

3.6.10

character datatype

Character datatype is a family of datatypes whose value spaces are character sets.

Note 1 to entry: The value space of the character datatype should be wide enough to represent every member of extended character set, if the repertoire list of characters to be stored in the character datatype is not specified explicitly.

3.6.11

octet datatype

Octet datatype is the datatype of 8-bit codes, as used for character sets and private encodings.

Note 1 to entry: The value space of the octet datatype is wide enough to represent every member of basic character set, but may not be wide enough to every member of extended character sets.

3.6.12

octet string datatype

Octet string datatype is the datatype of variable-length encoding using 8-bit codes.

Note 1 to entry: The octet string datatype may be used to represent a member of extended character sets.

3.6.13

multi-byte representation of character

A coded character represented by using a sequence of bytes (one-octet byte, two-octet byte, or four-octet byte).

Note 1 to entry: A character that is encoded by UTF-8 (UCS Transformation format) specified by a DAM of ISO/IEC 10646-1 and stored in an octet-string datatype is an example of the multi-byte representation of a character. The size of a coded character encoded by UTF-8 is up to six octets, therefore it may occupy up to 6 one-octet bytes in the octet string datatype.

Note 2 to entry: To handle the multi-byte representation of character correctly in an octet string datatype, the character boundary needs to be distinguished from the octet(s) boundary. Otherwise a multi-byte representation of character may be bisected as the result of octet base string manipulation, thus becoming no longer a character. In following reference the multi-byte representation of a character will be abbreviated as multi-byte character.

3.6.14

multi-octet representation of character

A coded character stored in a character datatype that size is equal to or larger than two octets with whose values are multiple octets.

Note 1 to entry: A character that is encoded by UCS-2 stored in a character datatype is an example of the multi-octet representation of character. The size of a coded character encoded by UCS-2 is always two octets, therefore it can be considered as a coded character that is represented by single two-octet byte.

Note 2 to entry: In following reference the multi-octet representation of a character will be abbreviated as the multi-octet character.

Note 3 to entry: A coded character represented by UTF-16 is categorized in both multi-byte and multi-octet character, because the byte size of UTF-16 is two-octet, but a character may occupy 1 or 2 two-octet bytes in a octet string datatype.

3.6.15

collation

The logical ordering of strings according to defined precedence rules.

3.6.16

cultural convention

A convention of an information system which is functionally equivalent between cultures, but may differ in presentation, operation behaviour or degree of importance.

Note 1 to entry: Time zone, Summer time, Date and time format, Numeric format, Monetary format, Collation sequence, and Character classification, are examples of cultural convention.

3.6.17

cultural convention set

A set of cultural conventions to be referred to by each programming language standard.

3.6.18

execution environment

An environment where a program is executed.

Note 1 to entry: An execution environment of program is not always the same as the compilation environment of the program.

Note 2 to entry: Coded character sets supported by execution environment and input from the environment to program may vary from one to another. For example, ISO/IEC 8859-1 may be supported by an environment, and ISO/IEC 10646-1 may be supported by another environment.

3.7.1

shall

An indication of a requirement on programming language standard or processors.

3.7.2

should

An indication of a recommendation to programming language standard or processors.

3.7.3

may

An indication of an optional feature of programming language standard or processors. When this Technical Report provides a recommendation to the programming language standard that supports a specific optional feature, the auxiliary verb “may” is used in the sentence explaining the condition.