(j3.2006) Comment 1 from TS Ballot

[Bill Long]

Hi All,

I tried sending this to the interop-tr email list but got an error 
message back from the server.  So I'm resending to the j3 list.  Sorry 
for duplicates if the original one worked.

=========

Hi All,

We need to create a response document for the comments made in the votes 
on the ISO TS ballot.  This email starts the discussion on the first 
comment.


The ISO ballot on the DTS for TS 29133 (Interoperability TS) resulted
in a total of two comments, both technical and from Germany.

The following starts the discussion of the first comment. Please, 
especially Reinhold, post to the list if you think I have misunderstood 
the intent of the comment.


-------From the Ballot Response for Comment 1-----------------

Technical comment 1 from Germany:

For an assumed-rank INTENT(OUT) dummy variable argument associated
with an assumed size actual argument (possibly across more than one
invocation level), the number of array elements to perform
finalization or deallocation of allocatable type components on is not
available. Note that in BIND(C) interfaces the above situation cannot
occur due to C1255b and C407a, but an assumed-rank entity may appear
in an interface that is not interoperable.

Preferred proposed change:

In 5.2p3, after C535b, add a new paragraph: "For a non-allocatable
non-pointer assumed-rank object that has the INTENT(OUT) attribute,
the SIZE intrinsic (6.4.2) shall return a non-negative value."

-------End of Ballot Response for Comment 1-------------------


The problem raised in the comment is illustrated by the following example:

module modu

    type c1_t
       real,allocatable :: x(:)
    end type

contains

    subroutine sub1 (asize)
    type(c1_t) :: asize(*)
    call sub2 (asize)   ! allowed??
    end subroutine sub1

    subroutine sub2(arank)
    type(c1_t),INTENT(OUT) :: arank(..)
    end subroutine sub2

end module modu

program test
   use modu
   type(c1_t) :: eshape(10)

   do i=1,10
      allocate(eshape(i)%x(100))
   end do

   call sub1 (eshape)
   print *, allocated(eshape(1)%x)  ! Expect F

end program

The issue arises because the call to sub2 results in the components of
its argument being deallocated because of the INTENT(OUT) attribute on
the dummy argument arank.  The proposed added paragraph would prohibit
an assumed-size actual argument being associated with an assumed-rank,
intent(out) dummy argument like the one in sub2.  The ultimate problem
is that the processor needs to know the size of the argument in order
to deallocate the correct number of component arrays.

Note that if sub2 was a BIND(C) subroutine the code would already be
disallowed because the argument type is not interoperable.


Proposed response for this example:

This case is already covered by the general
prohibition at [96:15] in Fortran 2008, which is not modified by the
TS, and states "An assumed-size array shall not appear in a context
that requires its shape.".  The appearance of asize in the call to sub2
violates this rule.  The proposed new text is effectively a restatement of
this rule for a particular case, and hence is unnecessary.

Comments, please...

1) Does the example accurately represent the intent of the comment?

2) Are there other cases included in the Ballot Comment that are not 
covered by the response?

3) Is the response correct?

...


Cheers,
Bill




-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101