variable in internal subroutine

[LRaim]

Using implicit definitions.

A variable JED calculated in internal subroutine INTA appears as undefined when used in internal subroutine INTB.

The variable JED is not defined nor used in the principal subroutine.

Is this defined by Fortran standard ?

[mecej4]

Local variables are, shall we say, local? If, indeed, you have two internal subroutines that declare JED, the two instances of JED are completely independent and are invisible to the main subroutine that contains those internal subroutines.

If you have JED declared in the main subroutine, as well, within the internal subroutines that variable is not accessible because the new declarations supersede the old.

You can ascertain all this for yourself by adding IMPLICIT NONE to your subprograms, internal and external.

[LRaim]

Ref. Mecej4 answer.

This is not what I am asking for. I know from years how to solve the problem and I do not want to use 'implicit none' since I can have hundredths of variables in most subroutines.
I have simply met the problem again :

SUBROUTINE ABC
  JED = 0
CALL  INTA
CALL  INTB
JEF = JEA + ....
RETURN

 CONTAINS
SUBROUTINE INTA
  JED = 1
END SUBROUTINE INTA
SUBROUTINE INTB
JEA = JED + 2
END SUBROUTINE INTB
END

If I forget setting  JED =0 , JED becomes undefined in INTB.

I have never found in compiler documentation a clear description about how variables are 'shared' between container and contained subroutines.

[mecej4]

If you do not have any reference or assignment to JED in the containing subroutine ABC, then the two instances of JED in the contained subroutines INTA and INTB are local variables, and in your example code there exist no variables with host association in INTA and INTB. In this situation the rules of host association are not at play.

What we have, therefore, are two subroutines with local variables that happen to be named the same. The rules about local variables are the same as in Fortran 77 and earlier. Variable names do not survive compilation, so the fact that JED in INTA has the same name as a variable in INTB has no effect. It is a programmer error to use a local variable that has not yet been defined.

[andrew_4619]

Mecej4's answer sums matter up nicely. If you do not use or declare something in the parent routine then the variable in the contained routine  is entirely local to that contained routine.

Luigi R. wrote:
.... I do not want to use 'implicit none' since I can have hundredths of variables in most subroutines.

I feel your pain, many of us have been in that position but what you are saying is  that you have hundreds of ways that you can have/introduce bugs that compiler would otherwise be able to flag up. Many years ago when I adopted the standard of having to explicitly declare everything I thought it was a real pain but I quickly found that it actually saves a lot of time in the end. Finding bugs can take a lot of time, and worse still what about the bugs you are not even aware of?

[dboggs]

Some of these comments go against the grain of what I thought I knew.

I thought that one of the primary reasons to use an internal subroutine is that it will automatically have access to local variables declared in the host (via "host association"), as well as the IMPLICIT NONE statement (so that it needn't be repeated). I do this all the time, and just to check, statements confirming this are easily found in some learning/reference books. So now I am confused. Possibly there is some issue of semantics? Maybe an example would clarify?

[mecej4]

Look again. The OP's question was more or less about access to variables that were neither declared nor used in the host (because he forgot to do either of these things in the host). In other words, this is about variables that were in his mind but not in the host.

[dboggs]

Perhaps some clarification is in order. Following are some quotes from the above discussion and what is really meant.

Yes I see it now, but it is easily missed. One thing that threw me off was the advice to add IMPLICIT NONE to all routines, external and internal. I think that is misleading. To summarize in my own words:

If a variable is used or declared in the host routine then it will be available to an internal routine--unless it is ALSO declared in the internal routine, in which case it is an independent variable. Also, an IMPLICIT NONE declaration in the host routine will carry over to an internal routine--you don't need to state it again.

So, really, IMPLICIT NONE should appear in all procedures EXCEPT an internal procedure (assuming it appears in the host).

[andrew_4619]

dboggs wrote:
So, really, IMPLICIT NONE should appear in all procedures EXCEPT an internal procedure (assuming it appears in the host).

You are indeed correct except for the word EXCEPT. To repeat the IMPLICIT NONE in the contained routine is redundant but doesn't do any harm either if you have it. I add IMPLICIT NONE on "autopilot" everywhere (and also set the compiler option) which covers all bases. I also fasten the seat belt in the car irrespective of if I think I will be having a car crash that day. :-)

[dboggs]

Did you used to work for the DOD (Department of Redundancy Department)? The dangers of redundancy have been well illustrated in this thread--i.e., you may not want to declare variables in an internal procedure if they were already declared in the host procedure, or the results may be unexpected! It's not analogous to simply being extra safe as in your seat belt example: there's no standard or default feature to hold you in the seat if you don't use the belt. 

[andrew_4619]

I said adding IMPLICIT NONE  I did not say anything about adding declarations. In this case they would not be redundant they change the meaning off the code. 

[dboggs]

Sorry, that should have been DRD not DOD.