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.