The types of portability problems encountered with I/O tend to be different for applications running with a host operating system versus embedded targets where the Ada run-time is self-sufficient. Interacting with a host operating system offers the added complexity of coexisting with the host file system structures (e.g., hierarchical directories), access methods (e.g., ISAM), and naming conventions (e.g., logical names and aliases based on the current directory). The section on Input/Output in ARTEWG (1986) provides some examples of this type of dependency. Embedded applications have different dependencies that often tie them to the low-level details of their hardware devices.
The major defense against these inherent implementation dependencies in I/O is to try to isolate their functionality in any given application. The majority of the following guidelines are focused in this direction.
Language Ref Manual references: 14 Input-Output
In this section...
7.7.2 File Closing
7.7.3 I/O on Access Types
|Summary of Guidelines from this section|
Formparameters on the predefined I/O packages. Declare and initialize them in an implementation dependency package.
Formstring or using a null value does not guarantee portability since the implementation is free to specify defaults.
Openprocedures that hide the visibility of the Form parameter entirely (see Pappas 1985, 54-55).
Language Ref Manual references: 14.2.1 File Management, 14.2.4 Direct Input-Output
The disposition of a closed temporary file may vary, perhaps affecting performance and space availability (ARTEWG 1986).
Language Ref Manual references: 14.2.1 File Management, 14.3.1 File Management
Consider the meaning of this operation. One possible implementation of the values of access types is virtual addresses. If you write such a value, how can you expect another program to read that value and make any sensible use of it? The value cannot be construed to refer to any meaningful location within the reader's address space, nor can a reader infer any information about the writer's address space from the value read. The latter is the same problem that the writer would have trying to interpret or use the value if it is read back in. To wit, a garbage collection and/or heap compaction scheme may have moved the item formerly accessed by that value, leaving that value "pointing" at space which is now being put to indeterminable uses by the underlying implementation.
Language Ref Manual references: 3.8 Access Types, 14.2.2 Sequential Input-Output, 14.2.4 Direct Input-Output
Low_Level_IOis intended to support direct interaction with physical devices that are usually unique to a given host or target environment. In addition, the data types provided to the procedures are implementation-defined. This allows vendors to define different interfaces to an identical device.
Low_Level_IOinterface which is portable in concept and general procedural interface, if not completely so in syntax and semantics.
Language Ref Manual references: 14.6 Low Level Input-Output