J3/14-197r1
To: J3
From: Nick Maclaren
Subject: Unresolved Technical Issues
Date: 2014 June 26
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
"An absent optional argument in a reference to an interoperable
procedure shall be indicated to and by C by passing a null pointer as
the actual argument."
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.}
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_attribute_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 the sections below."
{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.}