(j3.2006) (SC22WG5.4674) Result of the vote on N1904
John Reid
John.Reid
Fri Mar 23 06:36:21 EDT 2012
WG5,
Here is the final result of the vote on N1904. The only change since
Monday is that I have added Van's vote.
John.
-------------- next part --------------
ISO/IEC JTC1/SC22/WG5 N1910
Result of WG5 letter ballot on N1904
John Reid
N1908 asked this question
Please answer the following question "Is N1904 ready for forwarding to SC22
as the DTS?" in one of these ways.
1) Yes.
2) Yes, but I recommend the following changes.
3) No, for the following reasons.
4) Abstain.
The numbers of answers in each category were:
0 for 1) Yes.
1 for 2) Yes, but I recommend the following changes (Bader)
5 for 3) No, for the following reasons.
(Chen, Cohen, Long, Maclaren, Reid, Snyder)
0 for 4) Abstain.
The ballot has failed.
Here are the responses in detail
_______________________________________________________________________
Reinhold Bader 2) Yes, but I recommend the following changes.
(references are to N1904, unless indicated otherwise. Edits to clause 9
have been omitted).
(A) [p 9, Constraint C407a]: Based on the email discussion started by
Tobias Burnus, I agree with John Reid's conclusion that INTENT(OUT)
should be prohibited here.
Edit: In C407a, before "POINTER", insert "INTENT(OUT),"
(B) [p 10, para following C535b]: The complete paragraph appears to
be redundant. Its first sentence is covered by 7.2, and the
second sentence by the first sentence in 6.3. So either it
should be removed, or turned into a NOTE.
(C) [p 25, first sentence of Example 1] Replace "array to pass to"
by "array which can be passed to".
(D) [p 29, section 8.4, second bullet]: Change "C decriptor" to
"C descriptor"
(E) [p 29, NOTE 8.11]. The last sentence is perhaps a bit too vague.
I suggest replacing it by
"C programmers should note that modifying C descriptors in ways that
are inconsistent with Fortran semantics, or referencing or
defining data stored at addresses computed from the /base_addr/
member of a C descriptor that do not correspond to a subobject of
the described Fortran object will cause undefined behaviour."
(F) [p 29, section 8.5]. The last paragraph of this section seems to
be misplaced. I suggest moving it to become para 2 of 8.3.5.1, in
which case the text "functions described in 8.3.5" should be changed
to "macro and functions described in this subclause", and a similar
change should be done for the text "function defined in 8.3.5" later
in the paragraph.
(G) [p 30, NOTE 8.12] I suggest changing the NOTE's first sentence to
"The following example illustrates how a C descriptor becomes
undefined upon returning from a call to a C function."
(H) Consider the Fortran type definition
type :: fa
integer(c_int), allocatable :: i(:)
end type
and the following interface
interface
subroutine fa_alloc(o_fa) BIND(C)
type(fa), allocatable :: o_fa(:)
end subroutine
end interface
for which an implementation in C is assumed, which performs
allocation of the object via CFI_allocate. According to the
rules given in 8.7, this appears to be standard-conforming;
the descriptor on the C side would have a type member with
value CFI_type_other.
However, CFI_allocate in general would not have any
knowledge on how to set up the type component o_fa%i (in
particular if fa_alloc is invoked from C with an actual
argument created inside C); this would appear to be a
situation similar to that described in NOTE 5.4. The same
argument applies for the POINTER attribute.
I therefore suggest to add restrictions which prevent this
situation from occurring.
Required edits:
[p 10] Change C516 to
"C516 The ALLOCATABLE or POINTER attribute shall not be specified
for a dummy argument of a procedure that has a
/proc-language-binding-spec/ if it
(a) is of a type with default-initialized components, or
(b) is of a non-interoperable type that has type parameters,
final procedures, type-bound procedures or components
that have the ALLOCATABLE or POINTER attribute."
[p 24, section 8.3.5.5] In the description of the type argument of
CFI_establish, add
"If it has the value CFI_type_other, /dv/ shall not be the descriptor
for an object of a non-interoperable Fortran type that has type
parameters, final procedures, type-bound procedures or components
that have the ALLOCATABLE or POINTER attribute."
(one could also forbid CFI_type_other altogether. This would
prevent creating a descriptor whose base_addr points to an object of
C union type. Perhaps an entry CFI_type_union with a negative value
should be added to table 8.2?)
(I) The argument of (H) may also be applied to the case of an INTENT(OUT)
dummy. The last two paragraphs of 6.3 imply that in a C-to-C call it
is the responsibility of the C programmer to perform
deallocation for an ALLOCATABLE entity. However, in the case of
CFI_type_other corresponding to a non-interoperable type with
ALLOCATABLE type components there is no possibility for the C
programmer to do type component deallocation. I suggest to disallow
specifying INTENT(OUT) in this case.
Edit:
[8.7]: Add the restriction
"If a dummy argument in an interoperable interface is of a
non-interoperable type that is finalizable or has components
with the ALLOCATABLE attribute, it shall not have the
INTENT(OUT) attribute."
(J) If finalizers are not considered a special case of type-bound
procedures, explicitly adding them in at least some of the places
where the term "type-bound procedures" appears in N1904 may be
appropriate. The term occurs on pages 13, 20, 31, [36, 40].
(K) I am a bit surprised that it seems to be possible to have a
CLASS(foo) :: a(:)
assumed-shape dummy in an interoperable interface, while a
polymorphic scalar appears to be prohibited. Was this intended? If
not, an additional restriction is needed in 8.7, viz.
"If a dummy argument in an interoperable interface is polymorphic,
it shall be assumed-type."
Alternatively, one could liberalize things by adding another item to
the list of allowed dummies:
", or
(e) the dummy argument is a polymorphic scalar that is not assumed-
type, and corresponds to a formal parameter of the prototype that is
a pointer to CFI_cdesc_t" (and remove the "or" at the end of (c)).
I suspect the latter is more problematic, and therefore prefer the
former; in particular C516 could not be a constraint if the latter
is adopted (thanks to Tobias Burnus for pointing this out).
_______________________________________________________________________
Daniel Chen: I vote 3) No, for the following reasons.
a. There is an outstanding issue that the current TS allows TYPE(*) also
be INTENT(OUT). As discussed in J3/WG5 mailing lists, this should be
disallowed.
b. Edit is needed for C1255 possibly other places to allow allocatable
and pointer arguments.
c. coarray dummy argument should be disallowed
_______________________________________________________________________
Malcolm Cohen: No, for the following reasons.
REASON: Too many technical and editorial problems remain in the document.
Here are suggested edits to improve the document. Due to lack of time,
this only has fixes for some problems noted in subclauses 8.3 to 8.6.
8.3.1 Summary of contents, p1
After "The \cf{ISO_Fortran_binding.h} heading file"
change "contains the"
to "shall contain"
because this is a requirement (on the processor) not a statement of fact.
Later,
change "The contents of"
to "The types, macros, and functions declared in"
because it is physically impossible to use the "contents" of a header file
to allocate or deallocate anything.
8.3.5.1p1
After "The" change "macro" to "macros"
because there are several macros defined by ISO_Fortran_binding.h.
After "and functions described in"
change "this subclause" to "subclause 8.3"
because "this subclause" is 8.3.5.1, and it contains no macro or function!
8.3.5.1p3
End the last sentence with a full stop.
Maybe "as follows:" -> "as described in the following subclauses of 8.3.5."
Or
"The prototypes for these functions in \cf{ISO_Fortran_binding.h} shall be
consistent with the specifications in subclause 8.3."
because ungrammatical and not conforming to ISO guidelines.
8.4p1
There are no functions "specified here".
Perhaps "specified by this Technical Specification"?
If not, specify precisely which functions or which subclauses they lie in.
8.4, Note 8.11 [p29]
Do we really have to say "C programmers should note"?
In any case it is far too weakly worded (Reinhold's version does not really
improve this), here is my suggestion:
"A C function that modifies a C descriptor other than as permitted by this
Technical Specification will cause undefined behaviour."
BTW re Reinhold's version - pointer arithmetic beyond the limits of an object
is already undefined behaviour in C, so I think we need not (and should not)
say anything about that.
8.5p3, 1st bullet point,
after "INTENT(IN)" change "argument" to "attribute".
8.5p4 I agree with Reinhold that this is out of place here, since it is not
saying anything about "formal parameters". However his suggested wording
changes would be incorrect.
8.6, NOTE 8.12,
please change "ary" to "x". Having both "ary" and "array" in the same piece
of code looks like the programmer is poor at spelling and makes it too easy to
misunderstand any description.
same note, final sentence is completely misleading. "ary" (please, "x") does
not have the TARGET attribute and therefore any C pointer to a location inside
of X becomes undefined whether ARRAY has the TARGET/ASYNCHRONOUS attribute or
not. Perhaps you should make X into an array pointer and allocate it before
the call or something, anyway the example is hopeless as is.
_______________________________________________________________________
Bill Long: 3) No, for the following reasons.
There are two technical problems with N1904:
- Because INTENT(OUT) causes an argument to become undefined when the
routine is called, it coexists poorly with TYPE(*). The combination of
TYPE(*) and INTENT(OUT) should be disallowed.
- A more obscure, but more serious problem, is that the text of C1255,
while improved to allow OPTIONAL arguments, still requires that the
variables in a BIND(C) call be interoperable objects. The test in
15.3.5 disallows the very things the TS is intended to allow
(allocatable and pointer arguments). The requirement needs to be
weakened to interoperable types (not objects) and then additional
requirements to account for TYPE(*) arguments and coarray arguments.
An email thread on the J3/WG5 lists proposed solutions for this, but
the change is significant enough to justify another review (in my
opinion).
There are also more minor wording and typo fixes that were mentioned by
others that should be fixed since a new draft will be required anyway.
_______________________________________________________________________
Nick Maclaren: 3) No, for the following reasons:
(A) Page 9, C407a and page 13 6.3 paragraph 3. Email discussions
arising from Tobias Burnus's attempt at implementation indicate that
there are still significant problems with this and actual arguments that
have ALLOCATABLE or POINTER components, default-initialized components,
final subroutines, and perhaps more. Components with polymorphic types
may also be a problem, but I do not completely understand the existing
constraints on those.
These were considered during its design, but seem to have been
underestimated. With hindsight, I feel that the specification of
TYPE(*) is far too liberal.
Note that the proposals to simply forbid INTENT(OUT) together with
assumed-type exclude reasonable uses of INTENT(OUT) (e.g. for MPI
receive buffers), but some constraint along those lines seems the best
solution. The following is badly worded and may not be enough, but is
put forward as a possibility:
"If the actual argument corresponding to an assumed-type dummy argument
is of a type with default-initialized components, or of a type that has
has components that have the ALLOCATABLE or POINTER attributes, or are
of types with default-initialized components, the assumed-type entity
shall not have the INTENT(OUT) attribute."
I also feel that the lack of any such restrictions on INTENT(INOUT) or
no INTENT is very confusing, and will be misunderstood by some readers
who were not involved in the discussions; the following is a draft of a
note that might clarify the intent.
"NOTE 5.3 The purpose of assumed-type is to allow companion processors
to handle Fortran variables with arbitrary, but simple, types as raw
data or raw storage. All uses of it will be processor dependent, and
uses incompatible with Fortran syntax or semantics will be undefined."
(B) Page 10, C1255 and C516. Reinhold Bader's point (H) explains
that this has similar, though probably simpler, forms of the same
problem, and I remain concerned about polymorphic types. I believe that
the restriction should be that all non-assumed-type dummy arguments to
BIND(C) procedures should be of interoperable type, and interoperable
except that they are allowed the ALLOCATABLE or POINTER attributes,or
are of assumed shape, type or character length.
No wording is provided, though John Reid has posted a possibility on
the WG5 reflector.
(C) Page 20, 8.3.4 paragraph 8 and page 31, 8.7 paragraph 5. This
should also exclude components with type parameters, type-bound
procedures, final subroutines and possibly default-initialized
components and polymorphic types.
(D) Page 14 6.4.3. This does not describe the case of no DIM
argument for UBOUND. Better wording would be:
The description of the intrinsic function UBOUND in ISO/IEC 1539-1:2010
is changed for an assumed-rank object that is associated with an
assumed-size array; if DIM is present and equal to the rank of ARRAY,
the result of UBOUND(ARRAY,DIM,KIND) has a value equal to
LBOUND(ARRAY,DIM,KIND)-2 with KIND omitted from LBOUND if it was omitted
from UBOUND; if DIM is not present, the element RANK(ARRAY) of the
result vector has a value equal to LBOUND(ARRAY,DIM,KIND)-2.
(E) Passim. The term used in the standard is "final subroutine",
not "final procedure". This should be changed.
(F) 8.3.3 elem_len. Kind is not a C concept. "and kind" should
be removed.
_______________________________________________________________________
John Reid: 3) No, for the following reasons.
Page 9, C407a. After "that" add "does not have INTENT(OUT) and".
Reason: INTENT(OUT) causes the dummy argument to become undefined, so
is a sort of assignment. Allowing it is inconsistent with C407b - the
intention is that as assumed-type object be altered only by a C
function.
Page 10, C1255, line 2, change "or" to
", a variable that has the ALLOCATABLE or POINTER attribute, a variable
of assumed shape, a variable of assumed type, a variable of assumed
character length, or".
Reason: We are currently saying that all these variables are disallowed
as arguments of a procedure with the BIND attribute. This is at variance
with the whole intent of the TS. This change perhaps goes too far. It
allows a procedure to have the BIND attribute despite it being
impossible to write a C function prototype with which it interoperates.
If this is felt to be important, more constraints along the lines of
C516 could be added.
Page 17, 8.2, line 3 and page 20, end of para under Table 8.1. Change
"scalar or is an assumed-shape, explicit-shape, or assumed-size array"
to
"scalar, an array whose shape is known, or an assumed-size array"
or
"an object whose shape is known or an assumed-size array."
Reason: The present wording excludes the case of an actual argument
of assumed rank. It is also misleading since there is nothing in the
descriptor to distinguish an assumed-shape array from an explicit-shape
array (and no need for it).
In addition, I suggest this change:
Page 15, RANK. In the Example para, change "effective" to "actual".
Reason: The meaning is the same in this case, but the reader has to
think it through with "effective".
_______________________________________________________________________
Van Sybder: 3) No, for the following reasons.
I have noticed the same problems with TYPE(*), and C1255, that have
already been discussed at length in email exchanges.
_______________________________________________________________________
More information about the J3
mailing list