J3/98-240 Date: 1998/11/11 To: J3 From: interop Subject: Edits for Interoperability: Part 1 References: J3/98-239 All references are to J3/98-007r3. Type aliases ------------ Add the following subsection before [56:14], and renumber subsequent subsections. [[Begin subsection]] 4.6 Type aliases Type aliasing provides a method of data abstraction. A type alias statement does not define a new data type in the way that a derived type declaration does. Instead, it defines a name that can be used to define entities of a particular type, while hiding which type that is. 4.6.1 Type alias definition R4?? <> TYPEALIAS :: R4?? <> => Constraint: A shall not be the same as the name of any intrinsic type defined in this standard nor the same as any other accessible or derived type . Explicit or implicit declaration of an entity or component using a type alias name is identical to declaration using the for which it is an alias. [[Begin J3 note]] Need to make sure that s are permitted in typed allocations and array constructors. [[End J3 note]] [[Begin Note]] For example, the following declarations for X, Y and S TYPEALIAS :: DOUBLECOMPLEX => COMPLEX(KIND(1.0D0)), & & NEWTYPE => TYPE(DERIVED) TYPE(DOUBLECOMPLEX) :: X, Y TYPE(NEWTYPE) :: S are equivalent to the following declarations. COMPLEX(KIND(1.0D0)) :: X, Y TYPE(DERIVED) :: S [[End Note]] The type alias name can also be used as a structure constructor name, if it is an alias for a derived type. [[End subsection]] 2.1 After [10:12], add to R207: " <> " 4.5.5 After [53:35], add to R444: " <> " 4.5.5 After [53:39], add: "Constraint: shall be the name of an accessible type alias that is an alias for a derived type." Allow type aliases in 's: 5.1 After [59:26], add: " <> TYPE ( )" Allow type alias names to be use associated: 11.3.2 [224:27] after "derived types" add ", type aliases" Make type aliases local entities of class (1): 14.1.2 [317:36] after "derived types" add ", type aliases" Declaration of a prevents host association of anything with that name: 14.6.1.3 After [326:6], add: " (13) A in a ;" and renumber subsequent entries in the list. Derived types ------------- Edits for the BIND(C) attribute in a derived type definition. 4.5 [38:33], after "that type." add "If the definition of a derived type specifies BIND(C), the storage sequence is the same as that which would be required by the target C processor for interoperability for a C struct type that interoperates with an object of this derived type (16.2.2)." 4.5.1 After [39:25], add to R425: " <> BIND(C)" 4.5.1 [39:36], change "SEQUENCE shall not" to "neither SEQUENCE nor BIND(C) shall" 4.5.1 After [39:36], add: "Constraint: If BIND(C) is present, neither SEQUENCE nor a shall be present. Constraint: If BIND(C) is present, all derived types specified in component definitions shall have been specified with the BIND(C) . Constraint: CONTAINS shall not be present, if BIND(C) is present." 4.5.1 After [40:22], add: "Constraint: Neither POINTER nor ALLOCATABLE shall appear in a , if BIND(C) appeared on the . Constraint: A shall not appear, if BIND(C) appeared on the ." Dummy data objects ------------------ After [72:23], add the following subsection: [[Begin subsection]] 5.1.2.13 VALUE attribute The <> shall be specified only in the scoping unit of a subprogram or an interface block that was specified with the BIND(C) attribute, and shall be specified only for dummy arguments. The VALUE attribute implies the INTENT(IN) attribute. [[Begin note]] The name of the VALUE attribute is intended to be suggestive. Although a processor is not required to use "pass by value" an argument with the VALUE attribute, that might be a possible implementation. In particular, when the VALUE attribute is specified for a dummy argument in a procedure or subprogram that has the BIND(C) attribute, the processor shall use the same argument passing convention of the target C processor, which is often pass by value. [[End note]] [[End subsection]] After [77:18], add the following subsection: [[Begin subsection]] 5.3.12 VALUE statement R5?? <> VALUE [::] Constraint: A shall occur only in the of a subprogram or an interface body (12.3.2.1). The VALUE statement specifies the VALUE attribute (5.1.2.14) for a list of objects. [[End subsection]] After [10:12], add: " <> " After [59:40], add: " <> VALUE" After [60:19], after "INTENT" add ", VALUE" After [60:46], add "Constraint: If the VALUE attribute is specified, the PARAMETER, EXTERNAL, POINTER, ALLOCATABLE, DIMENSION, INTENT(INOUT) or INTENT(OUT) attribute shall not be specified. Constraint: If the VALUE attribute is specified for a dummy argument of type character, the length parameter shall be one, and shall not be an asterisk." 12.4.1.2 [241:29], after "has the TARGET attribute" add ", does not have the VALUE attribute" 12.4.1.2 [241:47+], add "If the dummy argument has the TARGET attribute and the VALUE attribute, any pointers associated with the dummy argument become undefined when execution of the procedure completes." New Interoperability section ---------------------------- Add the following new Section (16). [[Start new section]] Section 16: Interoperability with C [[Need an introduction here]] 16.1 The ISO_C_TYPES intrinsic module A processor shall provide the intrinsic module ISO_C_TYPES. This module shall make accessible the following entities: C_INT, C_SHORT, C_LONG, C_LONG_LONG, C_SIGNED_CHAR, C_FLOAT, C_DOUBLE, C_LONG_DOUBLE, C_COMPLEX, C_DOUBLE_COMPLEX, C_LONG_DOUBLE_COMPLEX, C_CHAR, C_PTR, C_LOC and C_NULLCHAR. The ISO_C_TYPES module shall not make accessible any other entity. C_INT, C_SHORT, C_LONG, C_LONG_LONG, C_SIGNED_CHAR, C_FLOAT, C_DOUBLE, C_LONG_DOUBLE, C_COMPLEX, C_DOUBLE_COMPLEX, C_LONG_DOUBLE_COMPLEX and C_CHAR shall be named constants of type default integer. The values of C_INT, C_SHORT, C_LONG, C_LONG_LONG and C_SIGNED_CHAR shall each be a representation method for integers that exists on the processor or shall be -1. C_FLOAT, C_DOUBLE and C_LONG_DOUBLE shall each have a value that specifies an approximation method for the real type that exists on the processor or shall have the value -1. The values of C_COMPLEX, C_DOUBLE_COMPLEX, and C_LONG_DOUBLE_COMPLEX shall be the same as the values of C_FLOAT, C_DOUBLE, and C_LONG_DOUBLE, respectively. The value of C_CHAR shall specify a representation method for characters that exists on the processor or shall have the value -1. C_NULLCHAR shall be a named constant of type character with a length parameter of one and kind parameter equal to the value of C_CHAR or equal to the default character kind if C_CHAR has the value -1. The value of C_NULLCHAR shall be the same as the null value of the C char type. C_PTR shall be a derived type or a type alias name. 16.2 Interoperation between Fortran entities and C entities A scalar entity or derived type component in the "Fortran type" column of Table 16.1, that has a kind type parameter that has the same value as the named constant made accessible from the ISO_C_TYPES module specified in the "Type kind" column, is said to interoperate with scalars or structure components of C types that are compatible with the C types in the corresponding row of the "C type" column. Table 16.1 Correspondence between Fortran types and kinds and C types +-------------------------------------------------------------+ | Fortran type | Type kind | C type | |--------------+-----------------------+----------------------| | INTEGER | C_INT | int | | | | signed int | | |-----------------------+----------------------| | | C_SHORT | short int | | | | signed short int | | |-----------------------+----------------------| | | C_LONG | long int | | | | signed long int | | |-----------------------+----------------------| | | C_LONG_LONG | long long int | | | | signed long long int | | |-----------------------+----------------------| | | C_SIGNED_CHAR | signed char | | | | unsigned char | |--------------+-----------------------+----------------------| | REAL | C_FLOAT | float | | |-----------------------+----------------------| | | C_DOUBLE | double | | |-----------------------+----------------------| | | C_LONG_DOUBLE | long double | |--------------+-----------------------+----------------------| | COMPLEX | C_COMPLEX | complex | | |-----------------------+----------------------| | | C_DOUBLE_COMPLEX | double complex | | |-----------------------+----------------------| | | C_LONG_DOUBLE_COMPLEX | long double complex | |--------------+-----------------------+----------------------| | CHARACTER | C_CHAR | char | +-------------------------------------------------------------+ [[Begin Note]] For example, a scalar object of type integer, with a kind parameter equal to the value of C_SHORT, interoperates with a scalar object of the C type short or of any C type derived (via typedef) from short. [[End Note]] [[Begin Note]] The C standard specifies that the representations for positive signed integers are the same as the representations for corresponding values of unsigned integers. Because Fortran does not provide direct support for unsigned kinds of integers, there ISO_C_TYPES module does not make accessible named constants C_UNSIGNED_INT, C_UNSIGNED_SHORT, C_UNSIGNED_LONG, C_UNSIGNED_LONG_LONG or C_UNSIGNED_CHAR. Instead a user can use the constants for the signed kinds of integers to access the unsigned kinds as well. Note that this has the potentially surprising side-effect that a scalar of the C type unsigned char interoperates with scalars of type integer with a kind type parameter of C_SIGNED_CHAR. [[End Note]] 16.2.1 Interoperation with C pointer types A Fortran scalar entity or derived type component of type C_PTR interoperates with C scalars or structure components that are of any C pointer type. [[Begin Note]] Note that this requires the representation method for all C pointer types to be the same for the C processor, if it is to be the target of interoperability of a Fortran processor. The C standard does not impose this requirement, so this may limit the ability of some processors to conform to Fortran 2000. Whether any C processors of interest actually take advantage of this needs to be determined. [[End Note]] [[Begin Note]] No facility for dereferencing of C pointers within Fortran is provided. [[End Note]] 16.2.2 Interoperation with C struct types A Fortran scalar object or derived type component of derived type is said to interoperate with a C scalar object or component of a struct type, if the derived type definition includes BIND(C) (4.5), the derived type and the struct type have the same number of components, and components of the derived type interoperate with the corresponding components of the struct type. A Fortran scalar object or derived type component of derived type cannot interoperate with a C scalar object or component of a struct type that contains a bit fields or an array of an incomplete type. [[Begin note]] For example, a C scalar object of type myctype interoperates with a Fortran scalar object of type myftype. typedef struct { int m, n; float r; } myctype; [[End note]] [[Begin note]] Note that the C standard requires the names and component names of two struct types to be the same in order for the types to be considered to be the same. This is similar to Fortran's rule describing when sequence derived types are considered to be the same type. This rule is not following for the purposes of determining whether a Fortran entity of derived type interopates with a C entity of a struct type. [[End note]] [[Begin note]] Note that a Fortran entity of derived type cannot interoperate with a C entity of a union type. [[End note]] 16.2.3 Interoperation with C array types An explicit-shape or assumed-size array of rank one interoperates with a C array if the element type of the C array is not an array type, an element of the Fortran array interoperates with an element of the C array, and (i) if the Fortran array is an explicit-shape array and the extent of the one dimension of the array is the same as the size of the C array; or (ii) if the Fortran array is an assumed-size array and the C array does not specify a size or specifies a size of *. An explicit-shape or assumed-size array of rank , where is greater than one, interoperates with a C array if a Fortran array of rank whose th dimension has the same extent as the th dimension of the original array, the extent of the first dimension of the array of rank is the same as the size of the C array, and the element type of the C array interoperates with the array of rank . [[Begin note]] For example, the Fortran array A interoperates with the C array b. INTEGER :: A(18, 3:7, *) int b[][5][18] [[End note]] 16.2.4 Interoperation with C functions If C type is "pointer to <>", the <> is <>. A Fortran procedure interoperates with a C function if: o the procedure is declared with the BIND(C) attribute; o the results of the procedure and the C function interoperate, if the Fortran procedure is a function, or the result type of the C function is void, if the Fortran procedure is a subroutine; o the number of dummy arguments of the Fortran procedure is equal to the number of formal parameters of the C function; o any dummy argument with the VALUE attribute interoperates with the corresponding formal parameter of the C function; and o any dummy argument without the VALUE attribute corresponds to a formal parameter of the C function that is of a pointer type, and the type of the dummy argument interoperates with the reference type of the formal parameter. The BIND(C) attribute shall not be specified for a subroutine or function if it it has asterisk dummy arguments. The BIND(C) attribute shall not be specified for a subroutine or function if it requires an explicit interface, unless the procedure is defined by a Fortran subprogram. [[Begin note]] Note that the requirement that the Fortran procedure not require an explicit interface prohibits dummy arguments from having the POINTER attribute, having the ALLOCATABLE attribute or being assumed-shape arrays. It also prohibits the Fortran procedure from being elemental or having an array result. [[End note]] [[Begin note]] For example, the Fortran function FUNC interoperates with the C function func. BIND(C) INTEGER(C_SHORT) FUNCTION FUNC(I, J, K, L, M) INTEGER(C_INT), VALUE :: I REAL(C_DOUBLE) :: J INTEGER(C_INT) :: K, L(10) TYPE(C_PTR), VALUE :: M END FUNCTION FUNC short func(int i; double *j; int *k; int l[10], void *m); [[End note]] [[Begin note]] Note that a C pointer may correspond to a Fortran dummy argument of type C_PTR, or to a Fortran scalar that does not have the VALUE attribute. [[End note]] [[End new section]] Make BIND(C) and VALUE characteristics 12.2, [230:5] After "elemental" add ", whether it has the BIND(C) attribute" 12.2.2.1, [230:15] Before "and whether" add "whether it has the VALUE attribute (5.1.2.13)," Handling of characters ---------------------- The following changes are needed to allow scalar characters of lengths other than one to be associated with C arrays of char. Edits: In 5.1.2.4.4 [69:38+] Add "(4) If the actual argument is of type default character and is a scalar that is not an array element or array element substring designator, the size of the dummy array is MAX(INT(l/e), 0), where e is the length of an element in the dummy character array, and l is the length of the actual argument." In 12.4.1.2 [240:44-45] Change "or array element substring" to "array element substring, or scalar" In 12.4.1.2 [240:46] After "array" add "or scalar" In 12.4.1.2 [242:2-3] Change "or a substring of such an element" to "or a scalar of type default character". In 12.4.1.5 [243:30] Change "an array element substring designator" to "a scalar of type default character" In 12.4.1.5 [243:39+] Add "If the actual argument is of type default character and is a scalar that is not an array element or array element substring designator, the element sequence consists of the character storage units of the actual argument."