P Suckling writes:
 > If someone has a moment to spare could they confirm something for me please? I
 > am not sure if I am interpreting a point in the standard correctly.
 >
 > Does section 16.5.7 point (10), regarding a variable with the INTENT(IN)
 > attribute mentioned in section 5.1.2.7 of the current standard mean that the
 > following (admittedly almost completely pointless) code is not allowed?

I assume you are looking at one of the f2k drafts, since there isn't
any section 16 in f90 or f95. Note that in quoting from f2k drafts,
one needs to specify which dfaft, because it is still changing. For
instance, I can't tell whether you are quoting from the CD or from the
new internal working draft that just came out on Friday. (It's only
an internal working draft - definitely not yet ready for the next
public review). For this question it doesn't matter, but for other
questions, it would.

The code in question is illegal, but not for reasons directly related
to that section. That section defines a term (variable definition
context) that is used in some places to express *SYNTACTIC*
constraints. All the places where it gets used really are syntactic
(and this compile-time checkable). When it talks about the appearance
of a variable, it means the syntactic appearance of that variable. It
is not talking about other things that might happen to be associated
with the variable for one reason or other.

The code is illegal for the following reasons (none of them related to
16.5.7).


1. 12.4.1.7(1) of the f2k CD (12.4.1.6(1) in f95).

   While actual_type%bob is associated with a dummy argument
   (i.e. while asub_sub is executing), there is action that
   affects its value (i.e. the assignment in the subroutine),
   and that action is taken other than through the dummy argument
   that actual_type%bob is associated. (It is taken through the
   other dummy argument).

   Yes, I know that particular bit of standard-speak is hard to
   read.

2. 12.4.1.7(2) of the f2k CD (12.4.1.6(2) in f95).

   This is closely related to item 1, but the code here does
   manage to violate both item 1 and item 2.

   The value of actual_type is affected in the subroutine through
   the dummy argument dummy_ttype. The value of actual type is also
   referenced in the subroutine other than through that dummy
   (it is referenced through the other dummy).

3. Neither of the above have anything to do with INTENT. If we throw
   INTENT into the stew, then I'd say the code also violates the first
   sentence after the constraints in 5.1.2.7 (F2k CD) or 5.1.2.3 (F95).
   Not the constraints themselves - those are syntactic and are what
   reference the the term "variable definition context". That sentence
   of text, however, is far more broad. It says that any way you might
   come up with to redefine the INTENT(IN) variable is illegal - no
   matter how devious a way it might be. Well, you've shown a slightly
   devious way (which also violates the rules in section 12, but ignore
   that for now).

Note that none of the above things you've violated are constraints.
The compiler is not required to detect the errors. In some cases,
most compilers almost certainly will not catch the errors. In this
case, with the subroutine in question being an internal one, the
compiler does at least have a reasonable chance of diagnosing it, but
is not required to. (And the vendor has a pretty obvious cost/benefit
tradeoff in terms of whether it is worth the development effort to
catch the cases like this vs the question of what fraction of user
errors this actually will find).


 > PROGRAM test_sub_call_prog
 >
 > IMPLICIT NONE
 >
 > TYPE test_type
 > INTEGER :: bob=0
 > END TYPE test_type
 >
 > TYPE(test_type) :: actual_ttype
 >
 > actual_ttype%bob=2
 >
 > CALL asub_sub(actual_ttype,actual_ttype%bob)
 >
 > PRINT *,'actual_ttype%bob: ',actual_ttype%bob
 >
 > CONTAINS
 >
 > SUBROUTINE asub_sub(dummy_ttype,dummy_bob)
 >
 > IMPLICIT NONE
 >
 > TYPE(test_type), INTENT(INOUT) :: dummy_ttype
 > INTEGER, INTENT(IN) :: dummy_bob
 >
 > dummy_ttype%bob=dummy_bob
 >
 > END SUBROUTINE asub_sub
 >
 > END PROGRAM test_sub_call_prog

--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
                             | -- Mark Twain