ISO/IEC JTC1/SC22/WG5 N1147 To: WG5 From: Michael Hennecke Subject: Draft Interoperability Report ********************************************************** Technical Report on Interoperability between Fortran and C ********************************************************** 0. NOTES ======== 0.0. Scope of this document The envisioned, though not yet specified, ISO Technical Report (Type 2) on Interoperability between Fortran and C (as outlined in WG5/N1131) MUST address the three following basic areas: 1. Name binding Providing language extensions to bind entities of C that have (C terminology for ) to Fortran entities, including the possibility of mapping possibly case-sensitive "binding names" to case-insensitive Fortran . 2. Datatype mapping Provide facilities to map C types to corresponding Fortran types. It has not yet been specified if this mapping should comprise all or just a "convenient" collection of "basic" types. 3. Procedure argument passing Provide facilities to change the Fortran language processor's implementation of procedure argument association, in order to adapt to the implementation of argument association used by the C language processor to be interoperated with. The WG5 documents N1096, 1089 and 1088 mention all of these aspects, as does the HPFF document on HPF/C interoperability (see SC22WG5.889). Note that none of the WG5 documents does propose a specific solution for (1). The HPFF proposal using a NAME('') clause with the EXTRINSIC interface is currently the most specific one. In my opinion, item (1) is almost independent from (2) and (3). To provide a starting point for the TR contents I propose a draft solution to the name binding problem, including a rationale and the edits that are necessary for inclusion of the name binding in N1122. A few comments on that proposal are given in section 0.1. For (2), there are only "notes" sections collecting some material to start from, in a form not suitable for direct inclusion in the TR and without detailed edits. For (3), no proposal exists so far. 0.1. Notes on name binding The scope of the TR does not require name binding for COMMON because it does not address the accessibility of global data declared in ISO C. But since the extension of a name binding mechanism to COMMON block names is trivial (once developed), it is proposed that a complete name binding facility is defined, including not only global C procedure names but also global C data object names. Secondly, only and names need to be extended with a name binding mechanism to allow access to all ISO C identifiers (for objects and functions) that have . For reasons of language regularity, the same mechanism may nevertheless be supplied for all Fortran names that are , even those that do not correspond to any C identifiers with . The problem with standard documents versus actual implementations is that no standard specifies what entries are generated for the linker. So there is no such thing as a F95_to_C binding, it is only possible to have a (or perhaps many) F95-Processor_to_C-Processor binding(s)! This problem is completely ignored in the HPFF proposal, providing a solution for de-facto implementations makes their life much easier. I think WG5 cannot rely on processor-dependent aspects for the TR specifications. Instead of the LANG= clause in a , I would very much like to provide the name of a procedure, which takes a CHARACTER string as input and produces another string as output. This would free the implementor of defining a list of C compilers (probably other vendors' :-) and shifts the name translation to a user-defined procedure. I don't know if this is really possible in F95, because that procedure must be referenced at compile-time. What does WG5 requirement 31 say about this? 0.2. Notes on datatype mapping The following is an unsorted list of informations from C and F95, to be assembled to a proper text... 0.2.1. Fortran types Fortran has and data types [F95, section 2.4.1]. The intrinsic types are the INTEGER, REAL, and COMPLEX [F95, section 4.3.1] and the CHARACTER and LOGICAL [F95, section 4.3.2]. All intrinsic types can be parameterized with the KIND type parameter. The CHARACTER type can also have the LEN type parameter. Derived types can be constructed from the intrinsic types [F95, section 4.4], and in F95 cannot be parameterized. They correspond to C structures. Fortran POINTERs are not types but to an "underlying" intrinsic or derived type. 0.2.2. C types The ISO C standard [ANSI C section 3.1.2.5 (Types)] distinguishes three different "classes" of types: [ANSI C,23:28+]: Types are partitioned into (types that describe objects), (type that describe functions), and (types that describe objects but lack information needed to determine their sizes). ISO C also distinguishes and : [ANSI C,24:12+]: The type #char#, the signed and unsigned integer types, and floating types are collectively called the . [ANSI C,24:21+]: Any number of can be constructed from the object, function and incomplete types, as follows: o An ... o A ... o A ... o A ... o A may be derived from a function type, an object type, or an incomplete type, called the . These methods of constructing derived types can be applied recursively. Mapping ISO C types to Fortran types should be done in two steps: mapping the and mapping (perhaps only a subset of) the . All the above are , they can be by #const#, #volatile#, or both of these qualifiers. These are similar to Fortran (#const# corresponds to PARAMETER, #volatile# has no counterpart in Fortran). 0.2.3. C type declarations The ISO C standard [ANSI C, section 3.5 (Declarations)] introduces the following legal combination of which must be mapped to adequate Fortran datatypes: void char signed char unsigned char [signed] short [int] unsigned short [int] [signed] [int] (including NO == IMPLICIT int) unsigned [int] [signed] long [int] unsigned long [int] float double long double Although C pointers are really a type and not only an attribute as in Fortran, they are not declared by a but by an appended to that type specifier [ANSI C, 3.5.4]. The declarator can be qualified like a type specifier. It is not clear if #enum# is a basic or a derived type. The standard does not assign it to one of these two categories. Kernighan/Ritchie (2nd ed.) list them under basic types... A as a is comparable to TYPE(type-name>) of Fortran and requires that name to be defined elsewhere. The definition of the is done in a declaration using a #typedef#. 0.2.4. Mapping of C basic types to Fortran A possible implementation may be through a Fortran MODULE providing KIND type values for the basic types. (In the case of signed and unsigned character types, these must provide KIND values for CHARACTER as well as for INTEGER type as these belong to both type classes. This resulted in generally appending one of the strings _kc, _ki, or _kr to the names). MODULE iso_c_kinds ! ! F90 Module to provide KIND values for the of ISO C ! ! "unsigned" kinds are identical to "signed" ones, ! TRANSFER semantics is implied when using these kinds ! IMPLICIT NONE ! KIND values for CHARACTER datatype (C ): ! INTEGER, PARAMETER :: c_char_kc = INTEGER, PARAMETER :: c_schar_kc = INTEGER, PARAMETER :: c_uchar_kc = c_schar_kc ! KIND values for INTEGER datatype (C ): ! INTEGER, PARAMETER :: c_schar_ki = INTEGER, PARAMETER :: c_uchar_ki = c_schar_ki INTEGER, PARAMETER :: c_shrt_ki = INTEGER, PARAMETER :: c_usort_ki = c_shrt_ki INTEGER, PARAMETER :: c_int_ki = INTEGER, PARAMETER :: c_uint_ki = c_int_ki INTEGER, PARAMETER :: c_long_ki = INTEGER, PARAMETER :: c_ulong_ki = c_long_ki ! KIND values for REAL datatype (C ): ! INTEGER, PARAMETER :: c_flt_kr = INTEGER, PARAMETER :: c_dbl_kr = INTEGER, PARAMETER :: c_ldbl_kr = END MODULE iso_c_kinds +---------------------------------------------------------------------------+ | Important Note: | | | | Traditionally, #int# and #long# designated the same C type which by | | the minimum-maxima requirements of ISO C had to be at least 32-bit. | | This fact caused the introduction of a (non-standard) C type #long long# | | to hold 64-bit integers. Although ISO C could also be implemented using | | #int# for 32-bit and #long# for 64-bit integers, this is rarely (if ever) | | the case for existing implementations: existing programs often assume | | #int# is equal to #long# -- non-conforming but too frequent to ignore. | | | | This TR may therefore wish to "standardize" the #long long# type, too... | +---------------------------------------------------------------------------+ 0.2.4a. Numerical limits of the C environment The ISO C standard requires that a conforming C implementation shall document all its numerical limits in the headers ## and ## ([ANSI C, section 2.2.4.2]). This section specifies two intrinsic modules that make these limits available in Fortran through variables having the same names as those defined in these headers. The values provided below are the minimum maxima required by the ISO C standard, conforming implementations may provide values with the same sign and a greater absolute value. MODULE iso_c_limits_h ! ! F95 module providing ISO C environmental limits from ! ! If the value of an C object of type char is treated as a signed ! integer when used in a C expression, CHAR_MIN = SCHAR_MIN and ! CHAR_MAX = SCHAR_MAX shall hold. Otherwise, CHAR_MIN = 0 and ! CHAR_MAX = UCHAR_MAX shall hold. ! ! Unsigned values are not supported in Fortran, so U*_MAX set to 0. ! USE iso_c_kinds IMPLICIT NONE INTEGER, PARAMETER :: CHAR_BIT = 8 INTEGER(c_schar_ki), PARAMETER :: SCHAR_MIN = -127_c_schar_ki INTEGER(c_schar_ki), PARAMETER :: SCHAR_MAX = 127_c_schar_ki INTEGER(c_uchar_ki), PARAMETER :: UCHAR_MAX = 0 INTEGER, PARAMETER :: CHAR_MIN = INTEGER, PARAMETER :: CHAR_MAX = INTEGER, PARAMETER :: MB_LEN_MAX = 1 INTEGER(c_shrt_ki), PARAMETER :: SHRT_MIN = -32767_c_shrt_ki INTEGER(c_shrt_ki), PARAMETER :: SHRT_MAX = 32767_c_shrt_ki INTEGER(c_ushrt_ki), PARAMETER : USHRT_MAX = 0 INTEGER(c_int_ki), PARAMETER :: INT_MIN = -32767_c_int_ki INTEGER(c_int_ki), PARAMETER :: INT_MAX = 32767_c_int_ki INTEGER(c_uint_ki), PARAMETER :: UINT_MAX = 0 INTEGER(c_long_ki), PARAMETER :: LONG_MIN = -2147483647_c_long_ki INTEGER(c_long_ki), PARAMETER :: LONG_MAX = 2147483647_c_long_ki INTEGER(c_ulong_ki), PARAMETER :: ULONG_MAX = 0 END MODULE iso_c_limits_h MODULE iso_c_float_h ! ! F95 module providing ISO C environmental limits from ! ! FLT_ROUNDS is set to -1 (indeterminable) here... ! USE iso_c_kinds IMPLICIT NONE INTEGER, PARAMETER :: FLT_ROUNDS = -1 INTEGER, PARAMETER :: FLT_RADIX = 2 INTEGER, PARAMETER :: FLT_MANT_DIG = INTEGER, PARAMETER :: DBL_MANT_DIG = INTEGER, PARAMETER :: LDBL_MANT_DIG = INTEGER, PARAMETER :: FLT_DIG = 6 INTEGER, PARAMETER :: DBL_DIG = 10 INTEGER, PARAMETER :: LDBL_DIG = 10 INTEGER, PARAMETER :: FLT_MIN_EXP = INTEGER, PARAMETER :: DBL_MIN_EXP = INTEGER, PARAMETER :: LDBL_MIN_EXP = INTEGER, PARAMETER :: FLT_MIN_10_EXP = -37 INTEGER, PARAMETER :: DBL_MIN_10_EXP = -37 INTEGER, PARAMETER :: LDBL_MIN_10_EXP = -37 INTEGER, PARAMETER :: FLT_MAX_EXP = INTEGER, PARAMETER :: DBL_MAX_EXP = INTEGER, PARAMETER :: LDBL_MAX_EXP = INTEGER, PARAMETER :: FLT_MAX_10_EXP = 37 INTEGER, PARAMETER :: DBL_MAX_10_EXP = 37 INTEGER, PARAMETER :: LDBL_MAX_10_EXP = 37 REAL(c_flt_kr), PARAMETER :: FLT_MAX = 1.0E37_c_flt_kr REAL(c_dbl_kr), PARAMETER :: DBL_MAX = 1.0E37_c_dbl_kr REAL(c_ldbl_kr), PARAMETER :: LDBL_MAX = 1.0E37_c_ldbl_kr REAL(c_flt_kr), PARAMETER :: FLT_EPSILON = 1.0E-5_c_flt_kr REAL(c_dbl_kr), PARAMETER :: DBL_EPSILON = 1.0E-9_c_dbl_kr REAL(c_ldbl_kr), PARAMETER :: LDBL_EPSILON = 1.0E-9_c_ldbl_kr REAL(c_flt_kr), PARAMETER :: FLT_MIN = 1.0E-37_c_flt_kr REAL(c_dbl_kr), PARAMETER :: DBL_MIN = 1.0E-37_c_dbl_kr REAL(c_ldbl_kr), PARAMETER :: LDBL_MIN = 1.0E-37_c_ldbl_kr END MODULE iso_c_float_h 0.2.5. Mapping of "other" C types to Fortran types 0.2.5.0. void [ANSI C,24:19+]: The #void# type comprises an empty set of values; it is an incomplete type that cannot be completed. The "function result type" void maps to Fortran SUBROUTINEs. The #void *# may be mapped to something like INTEGER(c_voidptr_ki) capable of representing an address. But I have not yet thought of pointers seriously... 0.2.5.1. array Should be straightforward, at least if the is a . The array element order for multidimensional arrays differs from C to Fortran. I do not propose a remapping option (as the HPFF proposal does). If remapping is really necessary, this can be done on the Fortran side after having recieved the array "as is", without any language extensions. 0.2.5.2. struct Components of structs shall not have incomplete type. However, they may be pointers to incomplete types (including the struct itself). Structs may contain bit-fieldls, which have no counterpart in Fortran. Addresses of structure components increase with component declaration order. There may be gaps between components due to alignment requirements of the components. The "internal" type declarations for #struct#s are not visible in C object files, they are "half-external" through C header files. Automatic mapping perhaps is too difficult. A quick solution might be to use an INTEGER (or even CHARACTER if alignment on byte boundaries is required) array having the same size as the C struct, and implying TRANSFER semantics between the C struct and the corresponding Fortran memory region. Perhaps this might even be implemented as a derived type (TYPE(c_struct), say) hiding these details, but I guess this would cause implementation problems if a type for all structs (with then necessarily dynamically sized component) is used. 0.2.5.3. union No idea yet. Perhaps a combination of struct and TRANSFER / EQUIVALENCE. 0.2.5.4. enum This type basically is a default integer type, INTEGER(c_int_ki): [ANSI C,24:19+]: An comprises a set of named integer constant values. Each distinct enumeration constitutes a different . The set of values is restricted in the C type declaration, and these values are given symbolic names. Might be implemented simply as INTEGER(c_int_ki) or as a derived type TYPE ! PRIVATE possible if processor supplies assignment from INTEGER... INTEGER(c_int_ki) :: val END TYPE The latter has the advantage that different C enum types having different "name spaces" now also have different Fortran TYPEs, even if the only component always is INTEGER. It makes assignment to and from enum-types more clumsy, but also allows the user (or processor) to overload assignment with a procedure that also restricts the valid values to those specified in C. Providing the symbolic names from C in Fortran can only be done by PARAMETERs, perhaps this is not really needed. 0.2.5.5. typedef This one may require TYPE aliasing on the Fortran side, see WG5 requirement 11. Using derived types is not a good idea because it implies component selectors. Handling typedefs for C function types is tricky if not impossible. 0.2.5.6. pointer No idea yet, but see 0.2.5.0. for void pointers which may be enough. 0.2.5.7. function Maybe not necessary here (no object type). 0.2.6. Mapping of Fortran intrinsic types to C types The mapping defined in 0.2.4 may be used in both directions. Fortran's LOGICALs may be mapped to C's integer types (including #char# for bytes), but if bit-wise LOGICALs are implemented then C structures with bit-fields may be required (this probably makes sense only for arrays). Fortran does not specify that .FALSE. is implemented as integer zero (.TRUE. being any non-zero integer), though. Fortran's COMPLEX may be mapped to a C struct with real and imag components. Since both languages do not specify the implementation (of COMPLEX and struct components), dummy fill-in might be necessary to ensure proper alignments. Mappings of any Fortran intrinsic type may be troublesome if more Fortran type KINDs are implemented than C has, e.g. more than three floating types. 0.2.7. Mapping of Fortran derived types to C types Do we really want to do this? 1. RATIONALE ============ 1.1. Rationale for name binding 1.1.1. C identifiers with external linkage Interoperability with ISO C requires that it is possible for a Fortran program to access those C entities that have in ISO C. (This term corresponds to Fortran's notion of .) [ANSI C, section 3.1.2.2 (Linkage of Identifiers), 22:6+] explains which C identifiers can have : objects and functions that have (or behave as if they had) the storage-class specifier #extern#. The only exception is when there is a visible declaration with that has the storage-class specifier #static#. In this case the object or function has , this corresponds to Fortran's PRIVATE attribute. Access to C entities that have external linkage is therefore possible if there is a facility to bind a Fortran to the corresponding C identifier. Comparing the Fortran specifications [F95, section 3.2.1 (Names), 22:36+] R304 <> [ ] ... Constraint: The maximum length of a name is 31 characters. [F95, section 3.1.1 (Letters), 21:25+] If a processor also permits lower-case letters, the lower-case letters are equivalent to the corresponding upper-case letters in program units except in a character context (3.3). with the related ISO C specifications [ANSI C, section 3.1.2 (Identifiers), 21:10+] <> The implementation shall treat at least the first 31 characters of an ... as significant. Corresponding lowercase and uppercase letters are different. The implementation may further restrict the significance of an (an identifier that has external linkage) to six characters and may ignore distinctions of alphabetic case for such names. These limitations on identifiers are all implementation-defined. ( Note that the restrictions on are labeled obsolescent in ) ( [ANSI C, section 3.9.1 (Future Language Directions/External Names), 96:2+]. ) ( Also note that "implementation-defined" in ISO C means that the C language ) ( processor shall document the behavior for this implementation dependence. ) shows the necessity to extend Fortran to allow access to case-sensitive C identifiers, and that this extension <> use character strings to provide case-sensitive information to the Fortran language processor. This proposal adds a new attribute to implement the name binding of C external identifiers to Fortran names. 1.1.2. Fortran names that are global entities To facilitate interoperability of other languages with Fortran, the proposed name binding mechanism is provided for all Fortran names that are , not only for and names which correspond to C entities with external linkage. [F95, section 14.1.1 (Scope of names/Global entities), 271:17+] explains that Program units, common blocks and external procedures are global entities of a program. Expanding "program unit" (see F95, Annex A) results in the following list:
, , , , , and . 1.1.3. Placement of the name binding facility The main location where name binding is necessary is the declaration of external procedures that are defined by means of ISO C. Other important places are the COMMON statement (to access global C data) and the Fortran program units whose names are global entities. External procedures can be declared either by an EXTERNAL attribute or statement, or by an interface block. It is therefore convenient to introduce a new attribute, , which can be used in all these places to specify the binding. For the sake of language regularity, a can occur in: * a which is a , * an in a type declaration statement for an external function, * a in a function or subroutine statement, * a , * the , and . The edits provided in section 3.1 of this technical report give detailed information about the exact inclusion of the in these contexts. 1.1.4. Form of the name binding attribute The form of the is specified in a new section 16.1 (Name binding) of the Fortran standard, which also forms section 2.1 of this technical report. The general form is BIND ( [NAME=] [, [LANG=] ] ) instead of a simple NAME() for the following reason: Neither Fortran nor ISO C specify which transformations a language processor may perform to process names for further use in the computing system, like generating object files and processing them by a linkage editor. However, knowledge or control of these transformations is required for portable mixed language processor programming (even within one language). It is therefore in general not sufficient to specify the name of a foreign-language identifier in the NAME= clause. This proposal allows the optional specification of a LANG= clause. If it is absent, the shall be used without any further transformation to generate "external symbols". If it is present, it specifies a language (or more correctly a language processor) whose transformation rules can then be applied by the Fortran language processor to generate external symbols, provided it is aware of that language (processor) and its transformation rules. If the is unknown, this has to be reported. Note: Although the specification of LANG='some-unix-c' may be equivalent to not specifying a LANG= clause (since most current implementations of C language processors on UNIX platforms do not perform name transformations), it will probably not be redundant to specify LANG='C370' because it is allowed by ISO C to limit external names to 6 characters and one case. 1.1.5. Relation of Fortran names and binding names !!! I cannot judge the range and implementation aspects of possible !!! !!! conflicts of Fortran names and the binding names generated from !!! !!! these when are used. !!! !!! The transformations normally applied by a language processor !!! !!! should guarantee that binding names for different (global) !!! !!! Fortran names without a are different. But what !!! !!! happens if a to one entity results in a binding name !!! !!! that is identical to the binding name of a different entity is !!! !!! not yet specified in this proposal! Comments are welcome... !!! 2. TECHNICAL SPECIFICATION ========================== This will be assembled from sections 1 and 3. 3. EDITS TO THE DRAFT STANDARD (N1122) ====================================== 3.1. Edits for name binding 3.1.1. New section 16 ........................................................................ Introduce a new section 16 (Interoperability with ISO C) ==> to be specified ........................................................................ Introduce a new subsection 16.1 (Name binding): <<16.1 Name binding>> Although this international standard generally does not specify the mechanisms by which programs are transformed for use on computing systems [section 1.4, clause (1)], this section introduces a mechanism to specify a <> (often abbreviated to <>) of a Fortran name to be used in further processing by the underlying computing system. This mechanism facilitates portable mixed language-processor programming, especially in cases where procedures defined by means other than Fortran have case-sensitive names that must be mapped to Fortran names. ........................................................................ Introduce a new subsubsection 16.1.0 (The binding attribute) <<16.1.0 The binding attribute>> The binding name for a Fortran name that is a can be established by a specification. This binding attribute may be used in a (16.1.1), as an in a type declaration statement for an external function, as a in a function or subroutine statement, in a , and in the , and . The rules for these specifications and statements restrict the use of the binding facility to global entities. This section defines the form and semantics of a binding specification. Riop1 <> BIND ( [NAME=] # # [,[LANG=]] ) Riop2 <> Riop3 <> If is not present or evaluates to "", the shall be taken literally by the processor to generate the binding for the Fortran name having that attribute. If is present and evaluates to a character string designating a language processor whose transformation rules are known to the processor, these transformations are applied to the to generate the binding for the Fortran name. If a language processor designated by is not known to the processor, it shall generate a corresponding warning message. In this case, the resulting binding name is processor dependent. ... some text discussing name conflicts, etc. ... The binding of a procedure name is part of the procedure's interface. ... what exactly does this mean ??? ... The binding of COMMON block names provide a means to access named global data objects of other languages. The layout of such COMMON blocks is dealt with in section 16.2 (Datatype mapping). Bindings of other program units have no explicit use within a Fortran program, but may be used by other language processors to access these program units. ........................................................................ Introduce a new subsubsection 16.1.1 (BIND statement) <<16.1.1 BIND statement>> A <> specifies the binding attribute for the name of an external procedure. Riop0 <> [::] Constraint: The shall be the name of an external procedure. ... some text ... ... Open questions: ... * do we allow COMMON block names? ... * do we allow names of other program units? ... (this would have the advantage that named constants defined in ... MODULEs would be available for all program units, they are NOT ... available for etc. which appear BEFORE any USE ... can appear in the source) ........................................................................ 3.1.2. Changes to existing sections ........................................................................ Update "Organization of this International Standard" on pages xiv++ ........................................................................ Section 1: Overview 1:22+ 1.4 Exclusions clause (1) and (2) may be affected 2:37+ 1.5 Conformance paragraph at line 37 may be affected ........................................................................ Section 1.9 Normative references Add lines 7:19+ ISO/IEC 9899:1990, Information technology -- Programming languages -- C (also ANSI X3.159-1989, American National Standard for Information Systems -- Programming Language -- C) ........................................................................ Section 2.1 High level syntax In 10:31-44 R214 <> <> ... add a line 10:32a <> ........................................................................ Section 5.1 Type declaration statements In 47:25-35 R503 <> PARAMETER <> ... add a line 47:27a <> In the Constraints list on page 48, add at 48:20a-20b Constraint: If a is specified, the shall be a single , and that entity shall be an external function. ........................................................................ Section 5.1.2 Attributes After section 5.1.2.2, insert a new section at 52:37a+: <<5.1.2.2a Binding attribute>> The <> specifies the name binding of an external function name. Name binding and related interoperability issues are described in section 16. This attribute may also be declared via the BIND statement (16.1.1). ........................................................................ Section 5.2 Attribute specification statements In 57:17, change This also applies to EXTERNAL and INTRINSIC statements. to This also applies to BIND, EXTERNAL and INTRINSIC statements. ........................................................................ Section 5.5.2 COMMON statement Change 68:12-14 R549 <> COMMON [/[]/] # # # # [[,]/[]/]... to 68:12-14a R549 <> COMMON [/[] []/] # # # # [[,]/[] []/ # # ]... ........................................................................ Section 11.1 Main Program Change 183:14 R1102 <> PROGRAM to R1102 <> [] PROGRAM ........................................................................ Section 11.3 Modules Change 184:21 R1105 <> MODULE to R1105 <> [] MODULE ........................................................................ Section 11.4 Block data program units Change 187:3 R1111 <> BLOCK DATA [block-data-name] to R1111 <> [] BLOCK DATA [block-data- name] ........................................................................ Section 12.3 Procedure interface In 190:30-32, change The interface consists of the characteristics of the procedure, the name of the procedure, the name and characteristics of each dummy argument, and the procedure's generic identifiers, if any. to The interface consists of the characteristics of the procedure, the name and binding of the procedure, the name and characteristics of each dummy argument, and the procedure's generic identifiers, if any. ........................................................................ Section 12.3.2.1 Procedure interface block on pages 191+ may be affected. ........................................................................ Section 12.5.2.2 Function subprogram In 205:33-36 R1219 <> <> RECURSIVE <> PURE <> ELEMENTAL add a line 205:33a <> In the Constraints list on page 205, add a new line 205:37a: Constraint: A shall only be specified for external procedures. ........................................................................ Section 12.5.3 Procedures defined by means other than Fortran may be affected. ........................................................................ Section 14.1 Scope of names may be affected. ........................................................................ Update Annex A (Glossary of technical terms): After 289:37, add the term <> with a definition After 294:3, add a line 294:3a <> (16.1): See . ........................................................................ Section C.9.2 Procedures defined by means other than Fortran (12.5.3) and section C.9.3 Procedure interfaces (12.3) on pages 329+ may be affected. ........................................................................ Update Annex D (Index) ........................................................................ REFERENCES ========== WG5 documents: o WG5/N1136 Improving the TR process in the context of the strategic plan (US) o WG5/N1131 Request for subdivision of project JTC1.22.02.01 to produce a Technical Report (Type 2) on Interoperability between Fortran and C o WG5/N1123 WG5 Plans for the Use of Type 2 Technical Reports to Accelerate the Development of Fortran Standards o WG5/N1122 CD for ISO/IEC 1539-1:1996 o WG5/N1116 Resolutions of the WG5 meeting on 17-21 April, 1995 in Tokyo, Japan (Resolution T9) o WG5/N1114 Draft NP for TR2 on Interoperability with C o WG5/N1111 Procedures for the Future Development of Urgent New Features in Fortran o WG5/N1096 Extrinsic C Interfaces o WG5/N1090 Inter-operability ( email contribution ) o WG5/N1089 Inter-operability o WG5/N1088 Interoperability and the CERN Program Library X3J3 documents: o 95-099, 95-114, 95-199, 95-200, 95-207, 95-219 Relevant items from the repository of requirements: o WG5 Repository: o 43: Procedure variables o 38: Improve Interoperability between Fortran and ANSI C o 38a: Improve Interoperability between Fortran and C o 37: Unsigned INTEGER Data Type o 11: Aliasing Type Definitions o X3J3 Repository: o 048: Improve Interoperability between Fortran and ANSI C o 037: Argument Passing Mechanism Related documents of the HPFF: o HPF calling C Interoperability Proposal, v1.2 o Multi Data Parallel Coordination with HPF, v1.2 (introduces a mapped array descriptor MAD) Submissions to the sc22wg5@dkuug.dk email list: o 920: Comments on N1131 (Interop TR) o 919: Interoperability TR web page o 889: intercallability with C o 870: C interoperability: HPF calling C proposal o 828: Project Editor for TR on Interoperability with C o 810: Interoperability with C o 790: Draft Interoperability Report (fwd) o 750: Re: (SC22WG5.743) Re: Interoperability o 746: Re: (SC22WG5.745) Re: Re: Interoperability o 745: Re: (SC22WG5.743) Re: Interoperability o 743: Re: (SC22WG5.742) Interoperability o 742: Interoperability The Programming in C pages by Jutta Degener, including the WG14 ftp archive and the ANSI C rationale. Review articles by Brian L. Meek discussing WG11 (Binding techniques) work: 1. Programming Languages: Towards Greater Commonality 2. A taxonomy of datatypes 3. What is a Procedure Call? Standards of JTC1 / SC22: o ISO/IEC 1539:1991 Fortran o ISO/IEC 9899:1990 C o ISO/IEC DIS 11404 Language-independent datatypes o ISO/IEC DIS 13886 Language-independent procedure calling o ISO/IEC TR 10182:1993 Guidelines for language bindings