jsh@usenix.org (Jeffrey S. Haemer) (03/28/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson) [ The sources to this, and the next two messages, are available on uunet.uu.net, in ~ftp/comp.std.unix/Updates/{9,17,b11}.mm. I will make further updates available there as I get them. -- mod ] An Update on UNIX-Related Standards Activities 1003.9: FORTRAN Bindings March 26, 1991 Joseph J. King, Ph.D. <JKing@GCG.Com> reports on the January 7-11, 1991 meeting in New Orleans, LA: POSIX is a set of portability standards that will span a diverse set of architectures such as VMS, UNIX, and OS/2. The FORTRAN binding to POSIX system services is nearing approval. Here I'll discuss the current state, including the relationship of language-independent POSIX standards to the FORTRAN language binding, and the possibility that the POSIX/FORTRAN binding will be rejected by the International Standards Organization (ISO). Portable Operating System Interface: POSIX A POSIX standard is one of a group of standards being developed by the Institute of Electric and Electronic Engineers (IEEE), in cooperation with the International Standards Organization (ISO). The primary mission of these standards is to define a portable user and application environment. The POSIX development effort is currently subdivided into 19 separate, numbered efforts - 1003.0 (POSIX Guide) through 1003.18 (PEP). Taken together, these groups are forming operating-system standards in the areas that range from networking to real-time. Half a dozen additional groups, also supervised by the IEEE's Technical Committee on Operating Systems, are creating related standards in areas like windowing toolkits. While POSIX started with UNIX as a model, POSIX standards are not limited to UNIX. For example, DIGITAL has announced a program that will incorporate some of the POSIX standards into VMS. Once adopted and implemented, POSIX standards will define a broad range of compatibility both within the UNIX family of operating systems and between other operating systems. POSIX and FORTRAN What follows is the January 1991 report on the progress of one of the POSIX working groups, POSIX.9. POSIX.9 is responsible for defining FORTRAN interfaces to the POSIX functionality defined by the other working groups. As a member of this committee I need to keep track of the progress of other committees to anticipate the next set of interfaces we will have to develop. At the moment there is only one published POSIX standard, which is referred to as POSIX.1. POSIX.1 defines the functionality and C interface to POSIX operating system services. POSIX.9 is currently in public review with a standard that defines FORTRAN interfaces to the POSIX.1 system services. In addition to providing interfaces to system services such as process creation and interrupt handling, the draft also defines interfaces that will improve FORTRAN application portability and interoperability. For example, the draft contains procedures for reading the command line arguments, performing stream I/O, inheriting open files, getting the time of day, access to system constants, access to system structures, and performing bit operations. ``Thick'' versus ``thin'' The FORTRAN binding to POSIX is referred to as a ``thin'' binding. That means that it defines the FORTRAN interfaces to access the POSIX system services, but does not define the functionality of those services. Instead, the FORTRAN binding references the POSIX.1 standard for the functional definitions. The Ada binding to POSIX is also nearing completion. It is a ``thick'' binding, in that it defines both the Ada interfaces and functionality. There are advantages and disadvantages to each approach. Thick bindings are easier to read, since all the information required is contained in one document. Also by using the thick approach it is easier to map the functionality into native-language constructs. The Ada-bindings group has done just this and has been praised for producing a binding that is very Ada-like (as opposed to C-like). Thin bindings constitute a more conservative approach. Since functionality is not defined in the thin binding, there is no opportunity for errors or inconsistencies to be introduced. Also, thin bindings are easier to adapt to changes in the base document. For example, the FORTRAN binding currently references the 1988 version of POSIX.1. Recently, however, POSIX.1 has been updated (1990) with several changes to functionality. After careful analysis at the January meeting, we determined that the FORTRAN binding requires only one substantive change to reference the 1990 standard as the base document. ISO Requires Language Independence The International Standards Organization (ISO) at one time required all POSIX functionality to be specified by language-independent standards. These are standards that specify functionality without specifying interfaces or syntax. Thin binding standards are then produced for each language to provide access to the functionality. In the last year ISO has relaxed this restriction to allow thick C bindings that define new functionality, but has excluded all other language bindings that do not reference a language-independent standard. Even though the FORTRAN binding is a thin binding it is based on the thick C binding and not a language-independent specification as ISO requires. This is because there is no language-independent specification and such a specification could be a year or more away. As a consequence, our working group will forward our draft for IEEE and ANSI processing when our work is complete. We will also ask ISO if they wish to adopt the IEEE standard at that time. This will give ISO another chance to say yes or no. We hope that they will adopt our binding at that time. If not, it may be several years before a language-independent standard is developed and we can produce a binding to it. We feel that our binding has usefulness in the FORTRAN community today, so that an ANSI standard even in the absence of an ISO standard would be useful. Other issues Other issues discussed at the January meeting included Fortran 90, the ballot process, and testing. There was some discussion of whether the POSIX.9 draft standard was Fortran-90-compatible. Since the FORTRAN binding to POSIX only requires FORTRAN 77 features it was agreed that our binding should be compatible with Fortran 90 compilers. We will look into this more carefully; however, after reviewing the areas in which Fortran 90 defines aspects for FORTRAN 77 that were previously undefined, I am confident that there are no conflicts that would prevent our binding from executing properly in a Fortran 90 environment. I presented a short summary of Fortran 90 features to the working group. There was a discussion of which Fortran 90 features might be used to increase the usability and portability of the Fortran binding. There was interest in using derived types and user-defined operators to create an unsigned data type for Fortran - complete with the necessary mathematical operations. There was also an opinion that we should limit the Fortran 90 features we use to those already in existence in common practice (e.g., structures and Include). This would have the advantage that our Fortran 90 binding would not require a full Fortran 90 implementation and the disadvantage of not making the most of Fortran 90 features. When this is printed we will be processing public ballot comments. The IEEE procedures for processing these comments was explained to us at this meeting. In order for our balloting to be successful, the following criteria must be met; 1. we must receive back at least 75% of the ballots sent out and 2. 75% of the yes-plus-no total must be yes. Ballots received will be of one of three types, yes, no, and abstain. If there are any no votes we are required to send out the objections to all those in the ballot group. They will then have the opportunity to change their vote. We will make changes to the draft and repeat this process until the necessary 75% is met and there are no new objections. We discussed writing test assertions for our current draft. These assertions are used by an implementor to prove conformance to the standard. It was agreed that, since the FORTRAN bindings is a thin standard, our test assertions would be a thin document. Work to be done There is still much work to be done. At our next meeting we will be processing the public ballot. We hope to a have a diverse range of opinions. We are hoping that an active balloting group will improve the quality of the standard. In this way, problems can be detected and fixed before they become part of the standard. If all goes well, that could be as soon as December 1991. Our next meeting will be in Chicago in April and you are welcome to attend. After that we meet in Santa Clara in July. [jsh -- Note that I changed this. Am I right?] Please contact either John, Loren, or me for details. John McGrory (Chair) Hewlett-Packard 19447 Pruneridge Ave Cupertino, CA 95014 mcgrory%hpda@hplabs.hp.com +1 (408) 447-0265 E. Loren Buhle, Jr., Ph.D. University of Pennsylvania School of Medicine Rm 440A 3401 Walnut Street Philadelphia, PA 19104 buhle@xrt.upenn.edu +1 (215) 622-3084 Joseph J. King, Ph.D. Genetics Computer Group 575 Science Drive, Suite B Madison, WI 52711 JKing@GCG.Com +1 (608) 231-5200 March 26, 1991 Standards Update 1003.9: FORTRAN Bindings POSIX .1 First published as IEEE 1003.1-1988, this standard has now been revised and updated, and achieved international status as ISO/IEC 9945-1 : 1990(E). Volume-Number: Volume 23, Number 20