(j3.2006) (SC22WG5.4674) Result of the vote on N1904

John Reid John.Reid
Fri Mar 23 06:36:21 EDT 2012


Here is the final result of the vote on N1904. The only change since 
Monday is that I have added Van's vote.

-------------- 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, 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

       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] 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.


     [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 
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.

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.
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, and it contains no macro or function!
End the last sentence with a full stop.
Maybe "as follows:" -> "as described in the following subclauses of 8.3.5."
  "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.

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 

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

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"
"scalar, an array whose shape is known, or an assumed-size array"
"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