According to Part I (section 5.1.3) of the Standard, an implementation of the language must document all implementation-dependent and -defined issues. This appendix summarises all characteristics of the language which in some manner depend upon the particular implementation of the language. It may thus be used as a checklist to be filled out for any given implementation.
It can also be a useful guide when preparing programs that potentially may be transferred to other manufacturers equipment. Keeping these points in mind when preparing a program may spare a programmer many a painful hour of debugging a program that behaves abnormally on some other host computer, while executing perfectly correct on his own system (or vice versa).
Extensions are allowed only if the following conditions are fulfilled:
Additional file access modes and access mode values to those defined in 10.1.1 may be defined by an implementation.
An implementation may provide additional subclasses of class file.
It is recognised that all language processing systems have some restrictions due to e.g. limited capacity of the underlying hardware. Such restrictions are not mentioned here.
An implementation may restrict the value range of the ISO-code construct, and the character set defined in table 1.1, as long as the "basic" characters of the table are included.
An implementation may restrict the number of different block levels at which a system class may be used as a prefix.
An implementation may restrict, in any way, the use of "file" and its subclasses for prefixing or block prefixing.
The type short integer is allowed to be unsupported by an implementation in the sense that it must then be mapped unto integer (i.e. the key word short is ignored).
The type long real is allowed to be unsupported by an implementation in the sense that it must then be mapped unto real (i.e. the key word long is ignored, and the special symbol "&&" is treated as "&").
An implementation may restrict the use of the standard access modes and their possible standard values; in that case the procedure "setaccess" must treat such values as unrecognised, and return false.
An implementation may restrict the number of block levels at which an external class declaration may occur.
An implementation may restrict the possible values of access mode BYTESIZE in any way.
Whether or not the procedure "terminate_program" will close open external files (except those associated with sysin and sysout), is implementation-defined.
The effect of a parameter to printfile.spacing with value zero, may be device and implementation dependent, if the standard effect of "overprint" cannot be achieved.
The interpretation of directive lines (apart from the "% "-convention) is implementation dependent.
The interpretation of "kind" and of the external identification string in an external procedure declaration is implementation dependent, as is the identification of a separately compiled module if no external identification is given.
The size of the part of the file that is actually locked after a call to procedure "lock", is implementation dependent.
The internal character set is implementation defined. An implementation is required to document the translation between the internal character set and the standard character set (as defined by ISO 646).
Note: The collating sequence of character (and text) values is decided by the internal character set. Thus the values of character and text relations are implementation-defined.
The values of "inlength" and "outlength" (see ch. 10) are implementation- defined.
The actual external files connected to SYSIN and SYSOUT are implementation- defined.
An implementation may define the actions to be taken when format effectors are included in the program (see 1.9).
The relative value range of real and long real is implementation- defined.
The ranges in which conversions from an integer type to a real type, or from real to long real, are exact, are implementation-defined.
The range of a numeric item in a de-editing procedure is implementation defined.
If the REAL ITEM located by text procedure "getreal" is an integer within an implementation defined range, the conversion is exact.
The EXPONENT of the numeric item resulting from "putreal" has a fixed, implementation-defined number of characters.
The function values of "char" and "rank" are implementation-defined.
The exact definitions of the standard mathematical functions are implementation-defined.
The values of the environmental enquiries are implementation-defined.
The association between a file object and an external file is implementation defined.
The effect of several file objects representing the same (external) file is implementation defined.
The details of procedures "open" and "close" are implementation-defined.
The interpretation of a function value of "lock" less than -1 is implementation-defined.
Directfile.outimage reacts in an implementation-defined way if the length of the internal image is incompatible with the format of the external file.
Directfile.locate may invoke implementation defined checks and possibly instructions to an external memory device.
Printfile.LINES_PER_PAGE: the value at object generation and after close is implementation defined.
The "basic drawing" algorithm is implementation defined.
The effect of the conditions demanded for the parameters to "linear" not being fulfilled, is implementation defined.
The number of decimals in the field for seconds of the function "datetime" is implementation-defined.
The effect of the parameters to "histo" not fulfilling the condition: length of A = length of B +1, is implementation defined.
The default BYTESIZE for bytefiles is implementation defined.
Evaluation of arithmetic expressions may give different results for different implementations.