J3/97-187r1 Date: 1997/05/15 To: J3 From: /interop Subject: U.S. Comments on Interoperability PDTR Ballot References: J3/97-154 (WG5 N1277 - 1st PDTR on Interop) The comments on the Interoperability PDTR ballot are divided amongst three J3 papers (this paper, J3/97-188 and J3/97-189). Note that there may be some overlap in the comments in these comments. Major technical issues ---------------------- 1.5 Is a processor permitted to make accessible entities in the ISO_C or other modules that are not defined by this PDTR? If so, the names may conflict with the name of a user-defined entity. This is similar to the issue Fortran has with permitting a standard-conforming processor to define intrinsic procedures that are not specified by the standard. 3.3.1, Note 3.10 Support for unsigned integers is still confusing. The paragraph after Note 3.10 notes that unsigned C types have the same size and alignment as their signed counterparts. However, it is not clear whether a positive signed number is guaranteed to have the same representation as an unsigned number with the same value. Does the C standard guarantee this? If we are assuming that the unsigned C types have the same representation as their associated signed types, there shouldn't be a need for the unsigned kinds, since there's no support real support in Fortran for unsigned values. 3.3.1, Note 3.11 It's not clear whether this note is suggesting things that an implementation needs to do to support the unsigned types or something the user needs to do. 3.3.2, Third paragraph This indicates that the values made accessible shall conform to the requirements of the C standard. What if that requires representation of values that are not model numbers in the Fortran model, e.g. -2**31-1? 3.3.3 Perhaps we could provide partial support for enum types with integer kind parameters named C_SCHAR_ENUM (for enums whose value is within the signed char range), C_SHORT_ENUM (for those whose value is within the short int range), etc. This may help in almost all cases, but does not necessarily solve the problem, since the C processor may not use straightforward rules in determining the representation for the enum type. Or perhaps a SELECTED_ENUM_KIND(LOW_ENUM, HIGH_ENUM). 3.3.6, Note 3.20 Note 3.20 suggests that sequence association could be used to circumvent the problem that C permits 12 array-specs, while Fortran supports 7 array dimensions. I assume that this is suggesting that the rank specified for the dummy argument in the interface block would be seven or less, while the C array had 8 or more array-specs. If this is correct, it conflicts with the normative text in the paragraph that follows the note, which states the extents in the Fortran array-spec are those specified in the corresponding C array declarators (in reverse order). I read that as requiring the ranks to be the same. If they are not required to be the same, sequence association needs to be explicitly permitted, and the rules must be spelled out. 3.3.7, Note 3.24 The situations in which a pointer becomes "stale" need to be specified. This should be similar to the list of events that cause variables to become undefined (14.7.6 of 1539-1). It should be normative rather than informative. 3.3.7, After C_DEREFERENCE A C_SET_DEREFERENCE (say) subroutine is desirable. This would provide a method of setting a value through a pointer. 3.3.7, C_ADDRESS, C_DEREFERENCE, C_INCREMENT Some of the arguments are permitted to be of any type. These should probably be restricted to be of types that are permitted in references to C procedures. Also, the argument to C_ADDRESS should be required to have the TARGET attribute; failing to require this severely hinders a processor's ability to perform optimization. In addition, should zero-sized objects be prohibited from appearing? 3.3.7, C_DEREFERENCE and C_INCREMENT Is the type of the MOLD argument specified permitted to be different from the type of the object from which the pointer was derived? Is C_INCREMENT permitted to specify an increment value that causes the dereference to exceed the bounds of an array? A user might expect to be able to do this in a case like the following: INTEGER, TARGET :: T1, T2 COMMON /COM/ T1(1), T2(1) PRINT *, C_DEREFERENCE(C_INCREMENT(C_ADDRESS(T1), T1, 1), T1) END 3.3.7, C_DEREFERENCE (Case (ii)) The description of the MOLD argument indicates that the MOLD argument shall be present if PTR is of type TYPE(C_STRUCT_PTR), but Case (ii) indicates that the result has the value of *(PTR), rather than expressing it as *((MOLD *)PTR). Shouldn't cases (ii) and (iii) be combined? 3.3.7, C_DEREFERENCE (Case (iii)) The dependence on the string being NUL-terminated seems unfriendly. There's no requirement that char * point to a C string. Perhaps it should return the value of (char *) ('h' in this case), making it more consistent with the other two cases. A separate set of procedures could be defined to handle the string case. 3.3.9, R1606 The syntax of the type-alias-stmt leads to an ambiguity in fixed source form. For example, is the following statement a pointer assignment or a type-alias-stmt? The :: is probably always required. type mytype=>integer ! Is this a pointer assignment? Also, it might be a good idea to permit of list of entities to be declared in a single type-alias-stmt. For example, type :: t1 => integer, t2 => real Some concerns were also expressed that the syntax of a declaration statement might cause people to confuse the objects declared with structures. 3.3.9, R1606 It might be worthwhile having a different keyword than TYPE to call attention to the fact that this is different 3.3.9, paragraph after Note 3.28 The use of the term structure-constructor is misleading, since the value is not necessarily a structure. Perhaps a new non-terminal symbol (alias-value-constructor, perhaps) is needed. In addition, the meaning of this constructor is unclear, especially for intrinsic types; what is the value of the expression, what is its type? 3.3.9, 1st paragraph after constraints after R1606 Rule R502 of IS 1539-1 needs to be extended to permit TYPE(type-alias-name) as a type-spec. 3.5, 1st paragraph This states that an explicit interface is required for a procedure defined by means of C, and that it have the BIND(C) attribute. Currently 1539-1 doesn't require this, so this requirement would cause conforming Fortran 95 programs to be non-conforming with respect to this TR. 3.5.1.1, 1st sentence Same comment as above. 3.5.2.1, 3rd paragraph The sentence that begins "ASSIGNMENT(=) for the types. . . " seems to describe something that is unnatural. The entire concept that conversions for actual arguments happen implicitly on procedure references is foreign to Fortran, but support for implicit defined assignment even when the defined assignment is not accessible is very strange. In addition, what happens when the user redefines assignment for these types? 3.5.3 The handling of seems clumsy. A suggested alternative would be to define a procedure in ISO_C_STDARG_H that has a variable number of arguments (similar to MAX and MIN). For example, call sub(va_list(i,j,k,a(17))) call sub(va_list(i,r)) 3.6 Some edits are needed to tie these objects in with the other global entities in 14.1.1 of 1539-1. One difference between these and other global entities is that it's not the name that is global, but the value specified by the name-string. Is the value of the name-string permitted to be the same as the name of any other global entity? Major editorial issues ---------------------- 4, New clause 16 This indicates that section 3 could be placed into IS 1539-1 almost unchanged. However, section 3 is not currently in a state that that could be done. For example, it would not be appropriate for Note 3.1 to appear in IS 1539-1. Also, the section contains rules and explanatory material that doesn't necessarily belong in a new section 16. For example, in 3.3.4, the first paragraph after Note 3.15 states "The POINTER component-attr-spec is not allowed because there is not C type whose corresponding Fortran type has the POINTER attribute." This more properly belongs in the edits to section 4.4.1 of IS 1539-1 as a constraint. Another example is the definition of the BIND statement in 3.2 rather than adding it as an edit to section 4 of IS 1539-1. 4, Annex D In most instances cross-references are left unqualified, so it is sometimes unclear whether the reference is to a section within the PDTR, a section in the Fortran DIS or a section in the ISO C standard. Minor technical and editorial issues ------------------------------------ 1.4, item 1 Change "Mixed-Language Input and Output" to "Mixed-language input and output" 1.4, item 4 Change "and some pointer types" to ", some pointer types, and bit fields" 1.5, paragraph after Note 1.1 Define "first-class language" 1.5, paragraph after Note 1.1 Section 1.5 of DIS 1539-1 states that a processor conforms if it "contains the the capability to detect and report the use within a submitted program unit of an additional form or relationship that is not permitted by the numbered syntax rules or their associated constraints". How should a conforming processor handle the additional forms and relationships specified by this PDTR? 2, 2nd paragraph after bulleted list Change "environment: Many" to "environment - many" 3.1, 2nd bullet in list Is "common definitions" a C term? If not, a different term should be used to avoid confusion with the Fortran meaning of the word "common". 3.1, First paragraph after Note 3.2 Change "facilites" to "facilities" 3.1, Paragraphs following Note 3.2 Should this document mandate the names of these modules without any specification of the contents? It's potentially confusing. 3.1, 1st paragraph after Note 3.3 "name" appears in italics once, but other occurrences are not italicized. 3.2, 1st paragraph after Note 3.6 Change "which" to "that" 3.2, Constraint after R1605 Change "which" to "that" 3.2, first constraint after R1604 Does the value of name-string include leading or trailing blanks? I assume so, but I just wanted to make sure since blanks are ignored in determining the value of an I/O specifier. 3.2, Note 3.6 Although the C standard requires that a C program not use two external names that are distinguished only by case, this TR needs to require a Fortran processor that does not support lower case letters have some facility to enable the mapping to the C external name. For example, int MyCFunc(void) {} INTERFACE BIND(C,NAME='MYCFUNC') INTEGER(C_INT) FUNCTION F() USE ISO_C END FUNCTION F END INTERFACE If the C processor preserves the case in the bind name for MyCFunc, the Fortran processor needs some way of getting to that name. It should probably be a method that's not specified in the TR, but still required. 3.3, Paragraph after Note 3.8 Change "datatypes: Derived" to "datatypes; derived" 3.3, Paragraph after Note 3.8 Change "recursively applied," to "recursively applied, and" 3.3.1, Table The names of the kind parameters should be listed before specifying which data types correspond to which C data types. 3.3.1, Table Change the kind parameter names to make them more similar to the corresponding C data types. For example, change "C_SHRT" to "C_SHORT". 3.3.1, Note 3.12 The TR should not give suggestions about possible extensions. 3.3.3 Change "implementation-defined: It" to "implementation-defined; it" 3.3.4, Last sentence of paragraph after Note 3.14 Replace with "A component-initialization shall not be specified for any component of a derived type that has the BIND(C) attribute." 3.3.4, Note 3.15 Change "the Fortran member objects" to "the Fortran derived type components" 3.3.4, Note 3.15 Change "way: The" to "way. The" 3.3.4, Paragraph after Note 3.16 Delete the sentence that begins "In either case, . . . ." It's not clear why the user might have thought that the length information would be stored in the structure. 3.3.5, Note 3.18 Delete the note entirely. We shouldn't give suggestions as to how to write non-conforming code. 3.3.6, Note 3.21 Change "the transposition must be done by the user" to "one can use the RESHAPE intrinsic with the ORDER argument present" 3.3.6, Last paragraph Change "may build on any" to "may build on either" 3.3.6, Last paragraph Should this paragraph be made into a note? 3.3.6, Last paragraph What does it mean for the Fortran binding to "build on" the C type? How can Fortran "build on" double *? 3.3.6, Description of C_ISNULL Change "Compares PTR to zero" to "Compares PTR to the appropriate C null pointer" (or something like that). 3.3.7, 2nd paragraph Change "are supported: The" to "are supported: the" 3.3.7, 2nd paragraph In which module is C_NULL defined? Also, where are the C_ISNULL, C_ADDRESS, et al. functions defined? 3.3.7, C_ISNULL, C_ADDRESS, et al. Each of these functions should probably be in a separate little section (as is done for the Fortran intrinsic procedures). 3.3.7, C_ISNULL Should this function be elemental rather than transformational? Is the function even necessary - why not provide operator(==) and operator(/=) instead? 3.3.7, Note 3.22 It's not clear what the first sentence of this note is trying to say. Shouldn't it be sufficient to say that the only operation that none of the operators is defined on these types. (I don't think it's really necessary to say even that much.) 3.3.7, C_DEREFERENCE Is the MOLD argument to be of a different type than the object from which the PTR argument was derived? 3.3.7, C_DEREFERENCE - Result value Case (i) Change "*((MOLD *) PTR) where PTR is . . . PTR." to "*((MOLD_T *) PTR), where PTR is . . . PTR, and MOLD_T is the type of MOLD." 3.3.7, C_DEREFERENCE - Result value Case (i) For the following example: integer(c_int) :: type(20) print *, C_DEREFERENCE(PTR, TYPE) is MOLD_T considered to be "int" or "int [20]"? 3.3.7, C_DEREFERENCE - Result and Example Case (iii) Change "ASCII NUL" to "NUL" (or whatever term is used to describe '\0' in the C standard - we don't want to require support for ASCII.) By the way, do we need to say something about '\0' being the same as CHAR(0, KIND=C_CHAR)? 3.3.7, C_DEREFERENCE - Example Case (iii) Change "character string of length 5" to "character string of length 6" (Is this the length returned by LEN or strlen?) 3.3.7, C_INCREMENT - Result value Change "(PTR *)((MOLD *)PTR+N) where PTR is . . . PTR." to "(PTR *)((MOLD_T *)PTR+N), where PTR is . . . PTR, and MOLD_T is the type of MOLD." 3.3.7, C_ADDRESS Why is the result value undefined if OBJ is of one of the pointer types and C_ISNULL(OBJ) is true? Shouldn't this procedure be returning a pointer to OBJ rather than a pointer to the objects OBJ points to? 3.3.7, Note 3.27 The first sentence of the note should remain. The remainder of the note should be replaced with an example that would be valid. There is no guarantee that the representation of void * will be the same as the representation of char **. If this functionality is actually required, a C_CHAR_PTR_PTR type should be defined. 3.3.7, Last paragraph This last paragraph should be made informative. 3.3.9, R1606 The meaning of the access-spec on the type-alias-stmt needs to be specified. Compare p.40, lines 39-41 of 1539-1. 3.3.9, 1st constraint after R1606 Change "1539" to "1539-1" (There are other instances as well.) 3.3.9, 2nd constraint after R1606 The second constraint isn't sufficient. The type-alias-name needs to be added to the list of local entities of class (1) in 1539-1 (14.1.2). 3.3.9, 1st paragraph after constraints after R1606 Change "used interchangeable" to "used interchangeably" 3.3.9, 1st paragraph after constraints after R1606 Change "type-spec: entities" to "type-spec. Entities" 3.3.9, Note 3.29 Change "hidded" to "hidden" 3.3.10 If we're not specifying the meaning of volatile at all, we shouldn't permit a Fortran entity to be associated with such an object. 3.3.10 Instead of specifying that if a C object of a const- qualified type is used in a way that violates the C standard, the object becomes undefined, shouldn't we specify that such an object is not permitted to become redefined? 3.3.11, Note 3.30 Delete "(which is comparable to Fortran PRIVATE entities)". 3.4.2, Argument As with the arguments to C_ADDRESS, et al., should the type be restricted? 3.4.2, Argument After "it shall be allocated." add "It shall not be an assumed-size array." 3.4.3, 2nd paragraph Change "follwing" to "following" 3.4.3, Description Change "strucure" to "structure" 3.4.3, Result Characteristics Change "imlementation" to "implementation" 3.4.3, OFFSETOF Should "OFFSETOF" be renamed "C_OFFSETOF" for consistency with the other functions defined? 3.4.3, Arguments of OFFSETOF There was some concern that it might not be clear that the MEMBER argument must be an "immediate" component of the TYPE argument rather than an ultimate component, say. 3.4.3, Arguments Should the TYPE argument be required to be of a type that has the BIND(C) attribute? 3.5.1, 1st paragraph Change "inluding" to "including" 3.5.1, Note 3.33 Change "parantheses" to "parentheses" 3.5.1, Note 3.33 Delete this note. It describes how a user might do something that is expressly prohibited by the normative text preceding the note. 3.5.1.1, 1st sentence Italicize "interface-body" 3.5.1.1, 2nd paragraph This states that if no name-string is present, the Fortran processor's rules are used to generate the external entry. Is this helpful? This means the user can't do anything portably if they don't specify the name-string. Why not specify that it's treated as if name-string was present with the value equal to the function-name or subroutine-name, with any lower-case letters converted to upper-case? 3.5.1.2, 1st paragraph after Note 3.34 Delete "The declaration of the function result variable shall be as follows:" 3.5.1.2, list following Note 3.34 Delete second bullet. It is confusing in a list of supported items and how they are supported. Also, delete sentence that reads "All other C pointer types are not supported." Instead, insert before 1st paragraph of 3.5.1.2, something like: "The return type of the C function shall be void, a basic type, a structure type, pointer to void, pointer to struct or pointer to char. The return type is not permitted to be an enumeration type, a union type or any other C pointer type." 3.5.1.3, Constraint after R1608 Remove quotes around asterisk - they are not part of the value. 3.5.1.3, Constraint after R1608 Why not permit blanks that are not significant as is done with I/O specifiers? 3.5.1.3, 1st paragraph after R1608 Change "pass-by-string this" to "pass-by-string. This" 3.5.1.3, 2nd paragraph after R1608 Change "A "*" character in the pass-by-string" to "If the value of the pass-by-string is "*", it" (Of course, the suggested modification will be affected by the following comment.) 3.5.1.3, 2nd paragraph after R1608 Should some more suggestive value for the pass-by-string be used other than '*' and ''? 3.5.1.3, 2nd paragraph after R1608 Reword the sentence that reads "A "*" character in the. . . "pointer to T"" As written, it implies that "pointer to T" is a Fortran type, whereas there are no pointer types in Fortran. 3.5.1.4, 2nd paragraph Delete "The Fortran declaration. . . as follows:" 3.5.1.4, 1st bulleted list Reword in a way that is consistent with the suggestion for 3.5.1.2. 3.5.1.4, 1st paragraph after Note 3.37 Change "type:" to "type." 3.5.1.4, last paragraph Change "All other C pointer types are not supported." to "No other C pointer types are permitted." 3.5.1.5, 4th bullet Change "A dummy argument or function result" to "A dummy argument" 3.5.1.5, After 4th bullet Add a new bullet "A function result shall not be an array." 3.5.1.5, 8th bullet Change "shall have an explicit interface, and that interface" to "shall have explicit interfaces, and those interfaces" 3.5.2.1 Change "If the dummy argument" to "If a dummy argument of a procedure with the BIND(C) attribute" in the 1st sentence of each paragraph. 3.5.2.1, last sentence before Note 3.43 Rather than indicating that the actual argument has to obey the same set of restrictions that something else obeys, repeat the restrictions for this case. 3.5.2.2 Change "If a dummy argument" to "If a dummy argument of a procedure with the BIND(C) attribute" in the 1st sentence of each paragraph. 3.5.2.3, Note 3.44 Delete this note. It should not be necessary to call the user's attention to this. 3.5.3, 1st paragraph Change "procedure interfaces." to "procedure interface." 3.5.3, Note 3.45 Delete this note. Each of Fortran and C is able to do things that the other cannot. 3.5.3, 4th bullet Change "to operands x1 of type" to "to operands x1 and x2 of type" 3.6, 1st sentence after Note 3.51 Change "additonal" to "additional" 3.6, 1st bullet after Note 3.51 Change "No initialization shall appear in the entity-decl." to "initialization shall not appear in an entity-decl in a type-declaration-stmt for a variable with the BIND(C) attribute." 3.6, 2nd bullet after Note 3.51 Change "ALLOCATABLE, PARAMETER or POINTER shall not be specified." to "A variable with the BIND(C) attribute shall not have the ALLOCATABLE, PARAMETER or the POINTER attribute, nor shall it be an automatic object, or a function result variable." 3.6, 3rd bullet after Note 3.51 Is it necessary to mention that CHARACTER with assumed character length is not permitted? This should follow from the fact that it is not permitted to be a dummy argument or named constant. 3.6 It should be noted when such a variable becomes defined (as is done in 14.7.5 of 1539-1 for variables which are initialized.) 3.6, last paragraph before Note 3.52 Change "If two or more. . . name-string are accessible in a scoping unit" to "If two or more. . . name-string" 3.6, last paragraph before Note 3.52 Change "They all refer to the same storage." to "All such variables are storage associated." 3.6, 1st paragraph after Note 3.52 Is this paragraph necessary? Shouldn't this follow from the definition of storage association? Perhaps it should be made into a note if it's felt to be necessary. 3.7, last paragraph It's not clear what this paragraph is saying. Is it talking about things like errno? Also, what does it mean to say that "The Fortran processor is not required to guard such behaviour"? 4, Edit for Page xvi Change "defined by Fortran code" to "defined by a Fortran module program unit" 4, 2nd constraint in edits for Page 38 Change "the same name-string" to "the same lang-keyword" (At least, I think that was what was intended.) 4, Edits for Page 38 Is BIND(FORTRAN) permitted to appear in a derived type definition? If so, what effect does it have? Should the SEQUENCE statement still be prohibited for that case? 4, Edits for Page 48 Change "may only" (two occurrences) to "shall only" Change "which" to "that"