(j3.2006) Comment 1 from TS Ballot
Bill Long
longb
Thu Sep 6 18:51:52 EDT 2012
I should have pointed out a more specific rule at [121:10-12] :
"An assumed-size array (5.3.8.5) is permitted to appear as a whole array
in an executable construct or specification expression only as an actual
argument in a procedure reference that does not require the shape."
If the dummy argument is intent(out) and the type has allocatable
components, then I would argue that the shape is required. There are
other cases where the shape would not be required (no intent(out), for
example). Would a Note following the above paragraph in Clause 6 be
appropriate / sufficient?
Cheers,
Bill
On 9/6/12 5:31 PM, Bader, Reinhold wrote:
> Hello Bill,
>
> ad 1) Yes.
>
> ad 2) I don't think so
>
> ad 3) I think relying on [96:15] in Fortran 2008 stretches things a bit. My understanding of that sentence could be paraphrased by "Don't use a descriptorless entity in places that require creation of a descriptor", and with assumed-rank we've created an exceptional situation where I think said sentence probably should be modified to
> "Unless for argument association with an assumed-rank dummy argument, an assumed-size array shall not appear in a context that requires its shape."
> (an additional edit in section 9 of the TS) in order to more unambiguously state that this special situation is permissible.
>
> I certainly also think that plugging this hole is more an exercise in consistency (and serves to assure implementors that a situation they cannot handle cannot occur) than of any practical importance (since it is not possible to construct an interoperable entity via a designator from a non-interoperable one anyway, C535b of the TS). So if people feel that
> [96:15] in Fortran 2008 cannot be misinterpreted to also disallow your example if you remove INTENT(OUT) from the declaration of arank in sub2, I'm game.
>
> Regards
> Reinhold
>
>
>> -----Urspr?ngliche Nachricht-----
>> Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-
>> fortran.org] Im Auftrag von Bill Long
>> Gesendet: Donnerstag, 6. September 2012 18:04
>> An: fortran standards email list for J3
>> Betreff: (j3.2006) Comment 1 from TS Ballot
>>
>> 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
>>
>>
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
--
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
More information about the J3
mailing list