(j3.2006) Allowed but not desired?
Tue Oct 7 21:57:13 EDT 2014
On Wed, 2014-10-08 at 10:45 +0900, Malcolm Cohen wrote:
> Van Snyder writes:
> This appears to be allowed, but I think it's not what we want:
> Actually I think it is not allowed to be used, and I think it is harmless
> module M
> type :: T1
> type(lock_type) :: L
> end type T1
> type :: T2
> type(t1), allocatable :: C
> end type T2
> subroutine S ( A )
> type(t2), intent(out) :: A
> This appears to be wrong, on two counts.
> First, the intent of C1303 is probably that A%C%L ought to be a coarray,
"C1303" was a typo. Should have been C1302. C1302 says a lock variable
shall be a coarray. No coarray in sight in the declaration of A.
> Well, I fundamentally disagree that that restriction is necessary or desirable.
> It is a coding guideline and not a particularly good one.
> Second, A has intent(out). The intent of C547 is that A%C%L not become
> undefined due to deallocation of A%C because A is intent(out).
> But A%C%L is not a subcomponent of A, because A%C is allocatable.
> Therefore, C547 does not apply.
> Is this what we wanted?
> (1) Yes the definition of the procedure is allowed. But it cannot be called
> (see 3).
> (2) The procedure is perfectly harmless because the lock variable is
> allocatable. Allocating/deallocating a lock variable needs to be known to the
> compiler (as it might require special OS action to set it up), but it is known
> so no problem. We allow deallocation of lock variables, even many of them at
> once, so no problem there. Allocating/deallocating a lock variable is not any
> kind of synchronisation (unless it is for some other reason e.g. the lock
> variable being an actual coarray in itself), so no problem there.
> The only problem with INTENT(OUT) comes for nonallocatable lock variables (which
> we absolutely do not want to just become "undefined"). Which C547 prohibits.
> So we seem to be fine on the procedure definition front.
> (3) It is impossible to call subroutine S because any actual argument will
> violate C1304. It looks like we could modify C1304 to prohibit just the
> problematic cases by inserting "nonallocatable" before "subobject". But given
> the current state and complexity of the whole LOCK_TYPE situation I don't have a
> lot of enthusiasm for that right now. Perhaps sometimes later when we have the
> situation straightened out enough to be both understandable and obviously
> correct (though that sounds a bit overoptimistic!).
More information about the J3