J3/14-197r2 To: J3 From: Nick Maclaren & Malcolm Cohen Subject: Unresolved Technical Issues Date: 2014 June 27 References: 14-118 This is a first cut at addressing the UTIs raised in 14-011. I have attempted to keep the meaning the same as the existing wording, but have had to rely on my memory of the intent in a couple of places. Specific technical aspects that should be considered are: UTI 04 - can anyone remember why we wanted the type to be only compatible? I am fairly sure that it was discussed, and vaguely remember that it was because C allows compatible-but-different aliasing (indeed, I may have suggested it). UTI 05 - do we need to say anything about Fortran->Fortran or C-C? I don't think so. The layout used for the former is irrelevant (i.e. the processor's business), and the latter up to the user - and not our business, anyway. UTI 07 - that entirely follows the intent, not the wording, because I looked at 16.5.2.5 and realised that the TS's wording was hopelessly incomplete. Note that the last is DEFINITELY a technical change, but not one that I think anyone will object to. Unresolved Technical Issue 04 ----------------------------- [439:3-6] 15.3.7 Interoperability of procedures and procedure interfaces, p4 Replace the whole of the paragraph before the bullet points "If a dummy argument ... argument as follows:" by "If a dummy argument in an interoperable interface is allocatable, assumed-shape, assumed-rank, or a pointer, the corresponding parameter value or argument in C shall be the address of a C descriptor for the actual argument. In this C descriptor, the members of the C descriptor other than attribute and type shall describe an object with the same characteristics as the actual argument. The value of the attribute member shall be compatible with the characteristics of the dummy argument. The type member shall have a value from Table 15.4 or a processor-dependent nonnegative type specifier value that depends on the actual argument as follows: {My understanding is that the difference between effective and actual argument is not relevant here. I cannot remember why we required the type to be only compatible.} Unresolved Technical Issue 05 ----------------------------- [439:14-19] 15.3.7 Interoperability of procedures and procedure interfaces, p5 Replace the whole paragraph by two paragraphs "When a Fortran statement calls a interoperable procedure written in C whose Fortran interface has a dummy argument with the CONTIGUOUS attribute, and the associated effective argument is not contiguous, the processor shall pass an associated argument to C that is contiguous. When a Fortran interoperable procedure whose Fortran interface has a dummy argument with the CONTIGUOUS attribute is called from C, the Fortran processor shall not assume that the actual argument is contiguous and shall treat it as a valid data object." {My understanding is that the difference between effective and actual argument is not relevant here. I don't think that we need say more. The last sentence in the replaced paragraph is merely a C coding recommendation.} Unresolved Technical Issue 06 ----------------------------- [439:20-22] 15.3.7 Interoperability of procedures and procedure interfaces, p6 Replace the whole paragraph by "If an actual argument in a reference to an interoperable procedure defined by means of C is absent, the C function is invoked the a null pointer for the corresponding argument. If an interoperable procedure defined by means of Fortran is invoked by a C function, an optional dummy argument is absent if and only if the corresponding argument in the invocation is a null pointer.". Unresolved Technical Issue 07 ----------------------------- [454:13-15] 15.8 Restrictions on lifetimes, p1 Replace the whole paragraph by "C descriptors and C pointers to any part of a Fortran object become undefined under the same conditions that the association status of a Fortran pointer assigned to that object as a target would become undefined (16.5.2.5), and any further use of them is undefined behavior (ISO/IEC 9899:1999, 3.4.3)." {No, I don't like that ungainly wording, but can't think of a better.} Note to editor: resolve singular vs. plural if possible, change ref to C99 to C+11. Unresolved Technical Issue 08 ----------------------------- [439:6] 15.3.7 Interoperability of procedures and procedure interfaces, p4 See UTI 04 for one change [439:11-12] 15.3.7 Interoperability of procedures and procedure interfaces, p4 Change "or correspond to CFI_type_other, one of the processor-dependent nonnegative type specifier values" to "CFI_type_other or a processor-dependent nonnegative type specifier value" [444:14+] 15.5.4 Macros and typedefs in ISO Fortran binding.h, p9 Append to the end of the paragraph "If such a type does not have a processor-defined value, the processor shall use CFI_type_other as a type specifier." Unresolved Technical Issue 09 ----------------------------- [441:7-14] 15.5.1 Summary of contents, p1 Replace the whole first sentence of the paragraph "The source file ISO_Fortran_binding.h ... and CFI_setpointer." by "The source file ISO_Fortran_binding.h shall contain the C structure definitions, typedef declarations, macro definitions and function prototypes specified in subclauses 15.5.2 to 15.5.5." {Is that a suitable way to phrase it?} [443:8] 15.5.4 Macros and typedefs in ISO Fortran binding.h, p1 Delete "The macros and typedefs described in this subclause are defined in ISO_Fortran_binding.h." {This replicates the requirement above, and is not present in 15.5.2, 15.5.3 and 15.5.5.}