J3/97-227R2 Date: 14 Aug 97 From: J3 To: William F. Mitchell Subject: Review of NISTIR 5985 J3 has reviewed NISTIR 5985, "A Fortran 90 Interface for OpenGL." Our review was limited to the NISTIR 5985 document itself; we have not tested or examined the reference module implementation. We believe this proposed binding to be worthwhile and the general technical approach to be good. We find specific merit in its appropriate use of modules and in its transparent treatment of the possible discrepancies in available type kinds between the C and Fortran implementations (section 2.2.1). The next revision of the Fortran standard is planned to incorporate interoperability features to facilitate calling C procedures from Fortran programs. These interoperability features should allow a portable implementation of the proposed binding. The existing C bindings plus the C interoperability features would constitute a Fortran binding, but this does not materially detract from the value of the binding proposed in NISTIR 5985 for several reasons: 1. The C interoperability features are still under development and are not scheduled to be formally approved in a standard for approximately 5 years. 2. The Fortran binding that would derive directly from the C binding plus the interoperability features would inevitably be less natural and convenient than a native Fortran binding like the one proposed in NISTIR 5985. It is likely that users would write their own wrappers to layer a more convenient binding on top of the one directly derived from C interoperability. By providing a standardized and portably implementable version of a natural Fortran binding, this proposal could head off the duplicative development of multiple incompatible wrappers. 3. The C interoperability features, when they are completed, could be viewed as enhancing the utility of this proposed binding by providing a portable means of implementing it. The following are some questions and suggestions for possible improvement. Most of these will be recognizable as being the same as comments submitted to you from other sources. They are repeated here to indicate J3's concurrence. - Section 1 The prefix f90 is probably overly specific. The f95 standard is in the process of being published, and a subsequent standard is under development. There should be no compatibility problems with using this binding with the subsequent versions of the standard, but the f90 in the names might seem a bit strange to the users. It is also not obvious why a prefix for the module procedure names is needed at all. Module procedure names are "mangled" in such a way that they do not conflict with global names. - Section 2.1 It should probably be explicitly stated that all of the definitions accessible from f90gl_kinds are also accessible from f90gl and f90glu. Section 3 says that "f90gl would use the module f90gl_kinds, which makes the kind parameters available to any program unit that uses f90gl." This does not necessarily follow as a conclusion; if this is the desired behavior, it must be specified. It is possible for f90gl to use f90gl_kinds without making the names imported from it accessible via f90gl. - Section 2.2.3, 1st paragraph This section mentions that some procedures require character string arguments, and states that in the Fortran interfaces, such dummy arguments are of type character with a length parameter of *. Do these procedures require their character arguments to be null terminated? If so, how is the null termination handled? Is the user required to specify it or will this be handled by "wrapper" routines? - Section 2.2.4 Most systems have more strict alignment requirements for an address than for character data. The choice of character here could affect performance on such systems. Maybe it would be better if C pointers were hidden inside of a derived type whose components are private. A logical function that tests for NULL could be provided instead of using f90glnullptr. It seems such an implementation would be much cleaner. Also, if the character string implementation does remain, the specification should just say that f90glnullptr is defined as the appropriate C null pointer, rather than specifying that it is necessarily equal to concatenated char(0) characters because the C null pointer might not necessarily be of this form. - Section 2.2.5, 1st paragraph, 5th sentence This sentence states that "Components that may be useful to the user are public, but other components may be private." Also, the example on the following page describes f90gluquadricobj as perhaps having "other components, which may be private" Were these uses of public and private meant in the Fortran 90 sense? If so, it's not possible to specify particular members of a derived type to be public while other are private. They must all be public or all private. Of course, a derived type with public components may have components of derived type with private components. Was that the situation that was being thought of? - Section 2.2.5, 3rd paragraph This paragraph states that "functions that return a C pointer to the struct, the fortran 90 returns a fortran pointer of the derived type." This conflicts with 2.2.4, which says that pointers will be treated as objects of type character. - Section 4.1 The 4th through 6th assumptions seem overly stringent. It would probably be relatively simple to work around the problems of using compilers that did not conform to these assumptions. - Section 4.2 This whole issue is a very thorny one. There are very strict circumstances under which a pointer to a dummy argument is considered to be associated with the actual argument when execution of the procedure completes. To begin, the actual argument must have the TARGET attribute. Also, either it must be a scalar, or the dummy argument must be an assumed-shape array and the actual must not be an array section with vector subscripts. Cases other than these leave the association status of the pointer in the referenced procedure either undefined or in a processor dependent state. The caller will have to ensure the actual argument obeys these rules, and the Fortran 90 interface to OpenGL will have to ensure the dummy arguments obey these rules. If any of these pointers created can be pointers to array dummy arguments (or elements of these), these dummy arguments have to be assumed-shape. This conflicts with the decision stated in 2.6 that array dummy arguments will be assumed size. - Section 4.3 The Fortran 90 standard requires BOZ constants to be nonnegative. The value Z'8000000A' is not representable as a positive 32 bit integer. Although this may work correctly, it is not standard conforming to do this. Minor editorial suggestions: - General The terms "Fortran" and "Fortran 90" should be capitalized and the term "FORTRAN 77" should be all caps. The document uses the terms "symbolic constant" and "defined constant" instead of the standard Fortran terminology "named constant." - Page 2, second bullet: Change "include statements" to either "include files" or to "INCLUDE lines". - 2.1, second paragraph: Change "parameter attribute" to "PARAMETER attribute" to bring the capitalization into line with Fortran 90 standard conventions. - 2.4, first paragraph: Same "parameter attribute" change as in 2.1. - 2.4, second paragraph: Change "symbolic constants (parameters)" to "named constant names". - 2.5, first paragraph: Change "external attribute" to "EXTERNAL attribute". - 3, last paragraph: Change "symbolic constants as integers with the parameter attribute" to "named constants as integer values".