J3/00-150 Date: 2000/03/02 To: J3 From: /interop Subject: New /interop unresolved issues References: 00-007, ISO/IEC: 9989-1999, 00-118, 00-121, 00-139 Issue 1: Add unresolved issues to make sure we check to see if we use the C terminology "linkage" and "external definition" (vs. declaration) correctly. A side issue in this discussion raised the issue as to whether we should permit initialization of variables with the BIND attribute. Edits: [65:2+] add J3 internal note: "Unresolved issue 238 We currently prohibit initialization of variables in COMMON or variables if the COMMON block or variable name has the BIND attribute. Should we relax that? If so, and if this discussion gets into whether the object is "owned" by C procedure where it is defined (in C sense, C standard 6.9) make sure we use concept of "external definition" correctly." [273:18+] add J3 internal note: "Unresolved issue 239 We are using the phrases "external linkage". We need to verify these terms are consistent with the C terminology "linkage" in the C standard (6.2). These terms are also used in section 16.2.7, Interoperation with C global variables." Issue 2: We do not discuss what happens if a main program is defined by means other than Fortran. How does all the magic "start-up" such as run-time system inititialization happen? Add unresolved issue to note this. Edit: [235:40+] add J3 internal note: "Unresolved issue 240 We need to note here or in chapter 16 that a main program may be defined by means other than Fortran. In addition, subclause 2.1 currently states that "A program shall contain exactly one ." This would need to change to require the to be omitted when main is provided by C. At that point we need to add a note or an Appendix C entry, for the benefit of implementors, stating that if a program mixes program units specified by means other than Fortran and program units specified by Fortran, the Fortran runtime must be initialized as well as the C runtime environment." Issue 3: What happens if a program terminates while executing a C function? For example, by calling exit(), returning from a C main() or reaching the closing "}" in a C main(), calling _Exit(), calling abort(), etc. We need to state the same program "clean-up" occurs as would happen if a program terminates while executing a Fortran program unit by executing a STOP statement or if the program terminates by "encountering" the END of a main program unit. "Clean-up" includes things like closing files, etc. Similarly, we need to state what happens if a program terminates while executing Fortran code. For example, reaching the END PROGRAM statement, executing a STOP statement. The C standard states that a value is returned to the system by main and that files are closed. Edit: [177:42+] add J3 internal note: "Unresolved issue 241 We need to discuss what happens if program termination occurs during exec- tion of a program unit defined by C, or if it occurs by C executing the exit() function. Clean-up work needs to occur for the Fortran runtime environment such as closing of files, ensuring all output from I/O appears in the appropriate files, etc. Conversly, we may need to also state that normal C clean-up occurs if termination occurs thru means defined by Fortran. A note or appendix C entry may indicate that such functionality could be provided if at startup time the housekeeping functions normal executed when a program terminates by a Fortran STOP or END statement are registered thru the C "atexit" library function." Issue 4: We need to make an edit which prohibits a procedure from calling C main(), and one which prohibits a program unit defined by means other than Fortran from calling a Fortran main program unit. Edit: [273:41+] add J3 internal note: "Unresolved issue 242 We need to prohibit a procedure from calling the C function main(), and also prohibit a C function from calling main() if there is a Fortran ." Issue 5: What do we do with C signal handling? Edit: [390:20+] add J3 internal note "Unresolved issue 243 Fortran now contains exception handling. We need to investigate what we need to say about C signal handling. What happens if an exception is raised while executing Fortran code, or if a C signal is raised while executing C code (do C signals affect Fortran exception handling, does Fortran exception handling affect C signals)? Can a Fortran procedure be installed as a signal handler? Does POSIX cover any of this?" Issue 6: Interaction of C and Fortran I/O Edit: [171:38+] add J3 internal note "Unresolved issue 244 We need to talk about interoperability of C I/O and Fortran I/O. Probably prohibit C and Fortran I/O to same files within a program. Other prohibitions? Unresolved issues 240 and 241 discuss related needs for defining initialization and finalization of I/O environments (ensuring start-up and clean-up work occurs for both languages, regardless of which language main is written in). Perhaps we should also have a note to say something about stdout, stdin, stderr vs. INPUT_UNIT, OUTPUT_UNIT and ERROR_UNIT. For example, we could state that they might all be associated with the same terminal device, for instance, and could be conceptually viewed as separate files, even though their records might actually be interleaved on the terminal." Issue 7: C 99 introduces the concept of Universal character names to provide a means of specifying identifiers with names composed of characters in the ISO 10646 character set through encoded hexadecimal values. This edit makes it clear that there was no intention to allow such C entities to be linked with Fortran entities. Edit: [79:15+] Add a new note "Note 5.xx The C standard provides a facility for creating C identifiers whose characters are not composed of the C basic character set. Such a C identifier is referred to as a Universal character name (6.4.3 of the C standard). The name of such a C identifier may include characters that are not part of the representation method used by the processor for type default character. If so, the C entity cannot be linked (12.5.3, 16.2.7.1) with a Fortran entity. This standard does not require a processor to provide a means of linking Fortran entities with C entities whose names are specified using the Universal character name facility." Issue 8: In C99, a pointer's value becomes indeterminate if it is pointing at an object when that object reaches the end of its lifetime. We need to state that a C_PTR in such a situation would become undefined. Edit: [359:38+] Add a J3 internal note "Unresolved issue 245 In C99, a pointer's value becomes indeterminate if it is pointing at an object when that object reaches the end of its lifetime. We need to state that an entity of type C_PTR in such a situation would become undefined." Issue 9: C 99 introduces two new types, _Bool and _Imaginary. Add new logical kind type C_BOOL to ISO_C_BINDING intrinsic module. Note, _Imaginary type can interoperate with reals, as its representation is that of a C float. Edits: [385:18] after "C_CHAR, " add "C_BOOL, " [386:6+] insert new paragraph "The value of C_BOOL shal be a valid value for a logical kind type parameter on the processor or shall be -1." [387:23+] In box with "float" add "float _Imaginary" [387:24+] In box with "double" add "double _Imaginary" [387:25+] In box with "long double" add "long double _Imaginary"" [387:29+] add new table entry "LOGICAL C_BOOL _Bool" Issue 10: 00-007 currently relies on the idea that C types that have the same representation are compatible types, and uses the term "compatible" in that way. In fact, that's not correct. For example, entities of type "int" and "const int" have the same representation in C, but the types are not actually compatible. Because Fortran provides no way of specifying the qualifiers that C can specify, other than volatile, the user is limited in the range of C entities with which to interoperate. Furthermore, 00-007 assumes that because an entity of type integer with kind C_INT, say, interoperates with a C entity of type int, it can also interoperate with a C entity of type unsigned int. However, that's not supported by the C standard, which makes it very clear that they are different types, and not compatible, even though the positive values of the signed type have the same representation as the corresponding values of the unsigned type. Edit: [386:30+] Add J3 internal note "Unresolved issue 246 The preceding text states that a scalar Fortran entity of a type and kind specified in Table 16.1 interoperates with a scalar C entity of a type that is compatible with the specified C type. However, we probably really want to say something like "of any type compatible (6.2.7 of the C standard) with or with the same representation (6.2.5 of the C standard) as the indicated C type". Making that change, if correct, allows a variable of type INTEGER(C_INT) to interoperate with variables of all of the types int, unsigned int, const int, register const volatile unsigned int, et al. Without that change, I believe such a variable can only interoperate with variables of type int or any typedef equivalent to int." Issue 11: 00-007 is silent on the issue of ellipsis. Subgroup believes the standard will either need to state explicitly that no Fortran procedure interoperates with a C function with ellipsis at the end of its parameter list or provide facilities for handling it. Edit: [390:20+] Add J3 internal note "Unresolved issue 247 We need to explicitly say something about ellipsis. Either state that a Fortran procedure does not interoperate with a C function with an ellipsis punctuator or make lots of ugly changes to deal with them from Fortran, like specifying ellipsis in an interface body, issues with resolving generic interfaces in the presence of ellipsis, problems with argument keywords in a reference to a procedure with ellipsis... . Not to make a value judgment." Issue 12: Should Fortran code have access to errno? Edit: [386:14+] Add J3 internal note "Unresolved issue 248 Should we provide facilities to set and query the value of errno?" Issue 13: There is a potential problem in the interaction of the setting of the IEEE rounding mode in Fortran code and in C code. Edit: [364:29+] Add J3 internal note "Unresolved issue 249 The preceding specifies that a Fortran subprogram must restore the rounding mode that was in effect on entry to the subprogram prior to returning to its caller. Because IEEE_SET_ROUNDING_MODE is the only procedure defined by this standard that affects rounding mode, a processor need only check whether a call to IEEE_SET_ROUNDING_MODE appeared in the subprogram in order to determine whether it is necessary to save the rounding mode on entry and restore it on return. A call to a C function might affect the rounding mode. How is a Fortran processor to deal with the preceding requirement in light of that fact? If it saves and restores the rounding mode around every call to a C procedure, that will destroy the performance of the program. The standard could require that a C function called from Fortran obey this same rule, since the Fortran processor itself can't conveniently enforce the rule." Issue 14: Subgroup didn't want setjmp and longjmp to jump through Fortran code. Edit: [273:41+] Add J3 internal note "Unresolved issue 250 We need to prohibit Fortran code from calling setjmp or longjmp, and prohibit C code from calling setjmp, and then calling Fortran code that calls C code that calls longjmp. Or we could prohibit the calls to setjmp and longjmp anywhere in a program that contains any Fortran program units." Issue 15: The C99 standard defines a header file named . This provides typedefs for exact-width integer types (e.g., int8_t), minimum-width integer types (e.g., int_least32_t) and fastest minimum-width integers types (e.g., uint_fastest16_t). It also provides a header file named that provides types ptrdiff_t, size_t and wchar_t. Some of the types in could be of use to users of Interoperability. However, of the types declared in , perhaps only size_t is of use. Edit: [385:24+] Add J3 internal note "Unresolved issue 251 We might want to make accessible kind parameters that help the user to declare entities that interoperate with entities of type int8_t, int_least16_t, uint_fastest32_t, et al. or type size_t." ------------------------------------------------------------------------- Issues 16-21 were raised by paper 00-121 (William Mitchell). Several of the issues in 00-121 have solutions with the current function- ality provided by interoperablity. Others raised in the paper cannot be fixed soley by changes to Fortran. Others could be fixed, but not without radical surgery to the document, and by adding functionality not currently in the scope of interoperability requirements. The following issues are those which subgroup and William Mitchell agreed should or will be done for F2K. Issue 16: It is critical for writing bindings to C libraries to have a capability to compare a C_PTR to a null pointer, or to compare two C_PTRs to one another. To do so, two things are needed. Edits: Section 16.1 [385:18-19] replace "and C_LOC." with "C_LOC, and C_NULL_PTR." [386:14+] add new paragraph "The entity C_NULL_PTR shall be a named constant of type C_PTR. The value of C_NULL_PTR shall be the same as the value NULL in C." "Unresolved issue 252 A new function, IF_C_PTRS_EQ(arg1,arg2) must be added to the list in first paragraph of 16.1 (not married to the name). The result is type logical, true if the arguments are equal, false otherwise. We need a new section in 16.2, "The C pointer compare operator", which describes this function. Discussion in subgroup examined several options, an IS_NULL function, an IS_EQUAL, extending .EQ. or ASSOCIATED. As C_PTRs are very different than Fortran POINTERs, subgroup rejected extending ASSOCIATED. A C_PTR can be a type alias which could map to an INTEGER type. Comparison with .EQ. could then degenerate to an INTEGER comparison for some implementation(s), and then comparison to an INTEGER constant would be possible. This was seen as getting dangerously close to progressing into defining pointer arithmetic; a can of worms we do not intend to open. Thus we settled on one C_PTR compare function, and an entity C_NULL_PTR which is a constant of type C_PTR which can be used as an argument in this function. We might also want to consider permitting an implementation to define assignment for type C_PTR. For instance, if a C processor maintains a use count with a pointer, a simple copy of the value through intrinsic assignment of an entity of type C_PTR might not give correct behaviour." Issue 17: The syntax for enums limits the number of enumerators which can be declared for each enum due to the limit of continuation lines. The syntax for enums will be changed to a "block structured" form, similar to a derived type declaration to correct this problem. Edits are planned for paper 00-149 at this meeting. Issue 18: The definition of the result of C_LOC should be made clearer. Edit: Section 16.2.3 [388:18+] Add J3 internal note "Unresolved issue 253 The description of C_LOC should be made more clear. Something like the following would be a start: The result is the same as would be returned by the C expression "<<&>>Y" (section 6.5.3.2 of C standard), if X appeared in the statement BIND(C,NAME="Y") :: X However, we also need to be able to take into account subobjects. We don't say anything about how elements of a Fortran array share storage with elements of a C array, or components of a structure with members of a C struct, etc. This ties into unresolved issue 219 (16.2.7.1) which points out that we don't say how changing the value of a C thing affects the linked Fortran thing and vice versa. Both issues can be addressed at the same time by building up a description of how elements, components, characters, etc. correspond with one another, then saying that defining/undefining one causes the other to become defined with the same value or undefined. When we have that, we can say that calling C_LOC for the Fortran thing is the same as applying <<&>> to the corresponding C thing." Issue 19: Wording of interoperation with C char strings should be clarified. Edit: Section 16.2.1 [386:38+] add J3 note "Unresolved issue 254 Perhaps a better description of what it means for C and Fortran character strings to interoperate is desirable. (See 3.6 of 00-121.)" Issue 20: Section 3.7 points out deficiencies with commandline arguments. Edit: [236:40+] Add J3 internal note "Unresolved issue 255 Paper 00-121, section 3.7 discusses problems with commandline arguments (argv). Paper 00-139, if passed resolves these issues." Issue 21: It is desireable to be able to call a MODULE PROCEDURE from a procedure defined by means other than Fortran. This edit also adds the edit from 00-118, item 5. Edit: Section 12.5.2.1 [266:10+] Add to existing J3 note (issue 151) "Additional information, meeting 152 It has been decided to allow module procedures to have a language binding spec. The above constraint must be removed, but there is an issue about the data in the specification part of the module which is not saved if the procedure is invoked but the module is out of scope. One solution is to make the appearance of a bind spec for a module procedure to imply SAVE for all entities in the specification part of a module. The potential issue of using a C_PTR to a module procedure (when BIND(C) is allowed) is exactly the same as the case of using a C_PTR to an external procedure that contains a common block or a USE statement. I.e. We must resolve what happens or what is allowed with C_PTRs anyway, allowing BIND(C) module procedures would not make this worse. Isn't the module out of scope problem already an issue in F95? Is the above also an issue for Fortran procedure pointers? The problem is not unique to interop. ---------------------------------------------------------------------------- Other additional issues: Issue: The parentheses are not required on a subroutine statement with no arguments. This results in a syntax ambiguity if BIND(C) is present, as the subroutine statement could be either a subroutine statement, or BIND attribute statement. BIND(C) SUBROUTINE JOE ! subroutine JOE or variable SUBROUTINEJOE? Similar ambiguities can occur when BIND(C) is allowed on an ENTRY statement (planned). Edit: Section 12.5.2.2 [269:24+] add J3 note "Unresolved issue 256 There is a syntax ambiguity if there are no arguments and the parenthsis are not present BIND(C) SUBROUTINE JOE ! attribute or subroutine statement Change syntax to make language binding spec a suffix spec similar to a function RESULT=. Change should also be applied to FUNCTION and ENTRY so syntax is similar for all."