J3/04-369
To: J3
From: Malcolm Cohen
Subject: Avoid obtaining a logical unit for opening
Date: 2004/08/10
Logical Unit numbers are processor dependent, there is no guaranteed way to
obtain one. Rules of thumb, such as "use a number greater than ten and
less than a hundred" are only somewhat portable. A standard intrinsic
procedure to find an unused unit number only alleviates some of the burden
of unit number handling, and does not help when maintaining or enhancing
legacy programs or libraries.
This proposal is for a standard opaque derived type to take the part of a
unit number. This type can be returned by the OPEN statement and used
everywhere that the existing unit numbers can be. Because it is opaque,
future expansion can easily be accommodated.
Number:
Title: IO_UNIT
Submitted By: J3
Status: For Consideration
References:
Requirements:
Have a mechanism for i/o units that
- does not confuse i/o units with integers (improved abstraction)
- does not require the user to manage their use (ease of use)
- avoids clashes between user-written code and existing third-party libraries
- avoids race conditions in multi-threaded programs, without requiring the
routine being used in a multi-threaded program to have different code
(viz explicit calls to locking routines) from when it is being used
without a threading library.
Basic Functionality:
Add a derived type to ISO_FORTRAN_ENV to represent an i/o unit. Allow
values of this type to be used everywhere that a unit number can be
used.
Rationale:
Logical unit numbers are processor-dependent, managing their use is difficult.
Integer values are not a good model of a file handle.
Simply finding a currently unused integer value is not sufficiently
powerful to avoid known problems with clashes and race conditions - having
a standard intrinsic to return an unused unit number can not help in this
regard, no matter how sophisticated we make the intrinsic.
Estimated Impact: Not Quite Trivial.
Detailed Specification:
(1) That a standard derived type, in the intrinsic module ISO_FORTRAN_ENV,
be provided to represent file handles. This derived type is referred to
as IO_UNIT hereafter.
(2) That the IO_UNIT type be opaque.
(3) That OPEN not be required to take a file unit number, but allowed to
return an IO_UNIT value instead.
(4) That an IO_UNIT value be usable in place of a in all
other i/o statements.
(5) That derived-type i/o subroutines not be modified; these will continue
to receive some processor-determined negative number for the unit -
because these are supplied by the processor and therefore cannot clash with
user-determined unit numbers, this is not a problem.
Syntax:
(1) That the derived type be named IO_UNIT.
(2a) That the UNIT= specifier on the OPEN be allowed to take a
TYPE(IO_UNIT) variable instead of an integer value,
or
(2b) That a new specifier IO_UNIT= be allowed on OPEN if
the UNIT= specifier is omitted.
Edits:
would be premature in the absence of an agreed base document.
Sections needing modification are:
9.4.0 The unit definition
9.4.5 the description of OPEN
13.8.2 to mention the derived type.
Discussion - an alternative:
----------------------------
Most of the requirements, except for the improved abstraction, could be
provided by a simpler proposal. This proposal would be to add a new
specifier NEW_UNIT=variable to the OPEN statement, which would return a
processor-generated unique negative unit number for the file being opened.
(This would be simpler to add to the standard, and have a smaller impact on
implementations, than adding a new type.)
History: Submitted as 04-369 at meeting 169.