Peter Shenkin writes:
> SUBROUTINE foo( n, a )
> INTEGER,INTENT(IN) :: n
> INTEGER,INTENT(OUT) :: a
> IF( n .EQ. 1 ) a = 47
> END SUBROUTINE foo
>
> What we're saying is that INTENT(OUT) is unsafe for a, because if we enter
> foo with n.NE.1, we might copy out 'a' with garbage in it. Is this
> understanding correct?
Yes. So the calling routine better not subsequently reference the
actual argument corresponding to A if n was other than 1.
> Just checking, since I didn't follow the beginning of this thread.
> If this is right, it certainly is a trap for the unwary, as Jim implies.
Guess I don't really understand this. Thats fundamentally what
INTENT(OUT) means - that the subroutine is solely responsible for
the definition of A. Yes, if you use a feature that you fundamentally
don't understand, and as a consequence use it incorrectly, then you
were unwary and were caught in a trap. As such things go, this one
doesn't strike me personally as being overly subtle.
To me, it seems almost identical to the case of a function
x = some_function(y)
Would you expect x to retain its previous value in a case where the
function failed to define its result variable? I wouldn't. An
INTENT(OUT) dummy argument is in my mind very simillar to a function
result variable from that point of view.
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|