local variable initilization [Fortran]

Prev: Can I create header file dependent by gfortran
Next: Can I create header file dependent by gfortran

From: Mike on 23 Apr 2008 23:37

Hi

module A
contains
subroutine subA()
real :: x
print *,'before adding',x
x=x+1
print *,'after adding',x
end subroutine subA
end module A
program main
use A
x=100.
call subA()
print *,'first output in main:',x
call subA()
print *,'second output in main:',x
end program main

The results are (CVF6.6c used):
before adding 0
after adding 1
first output in main: 100
before adding 1 <=== why?
after adding 2
second output in main: 100

Why? Isn't x in subA a local variable? I read the Chapman's book,
which shows "the values of all the local variables and arrays in a
procedure become undefined whenever we exit the procedure." I thought
x=0. x doesn't have SAVE attribute in subA.

Mike

From: jamesgiles on 23 Apr 2008 23:56

On Apr 23, 9:37 pm, Mike <Sulfate...(a)gmail.com> wrote:
...
> [...] Isn't x in subA a local variable? I read the Chapman's book,
> which shows "the values of all the local variables and arrays in a
> procedure become undefined whenever we exit the procedure." I thought
> x=0. x doesn't have SAVE attribute in subA.

Undefined doesn't mean that it has no value. It doesn't mean that it
does either. Indeed, since you never assigned to X before the first
time you printed it, it was undefined there too. Undefined means that
it's non-standard to try to make any use of the value. If you do, the
implementation is free to do anything it likes.

In this case, it appears to be clearing all vars in module procedures
to zero at the beginning of the run and then preserving the value
across calls. That's a pretty benign way of doing things and well
within the privileges of the implementation. Especially since the
usual hyperbole about what implementations are permitted to do when
you violate the standard is "it can do anything including start World
War Three!"

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

From: James Van Buskirk on 24 Apr 2008 00:56

"Mike" <SulfateIon(a)gmail.com> wrote in message
news:0654907e-38f6-4219-a50b-eeda352ea800(a)i76g2000hsf.googlegroups.com...

> Why? Isn't x in subA a local variable? I read the Chapman's book,
> which shows "the values of all the local variables and arrays in a
> procedure become undefined whenever we exit the procedure." I thought
> x=0. x doesn't have SAVE attribute in subA.

If it makes you any happier, you can try compiling with the
/recursive switch.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

From: Herman D. Knoble on 24 Apr 2008 07:29

From: blitheli on 24 Apr 2008 09:06

On 4ÔÂ24ÈÕ, ÉÏÎç11Ê±37·Ö, Mike <Sulfate...(a)gmail.com> wrote:
> Hi
>
> module A
> contains
> subroutine subA()
> real :: x
> print *,'before adding',x
> x=x+1
> print *,'after adding',x
> end subroutine subA
> end module A
> program main
> use A
> x=100.
> call subA()
> print *,'first output in main:',x
> call subA()
> print *,'second output in main:',x
> end program main
>
> The results are (CVF6.6c used):
> before adding 0
> after adding 1
> first output in main: 100
> before adding 1 <=== why?
> after adding 2
> second output in main: 100
>
> Why? Isn't x in subA a local variable? I read the Chapman's book,
> which shows "the values of all the local variables and arrays in a
> procedure become undefined whenever we exit the procedure." I thought
> x=0. x doesn't have SAVE attribute in subA.
>
> Mike

the default for the values of all the local variables and arrays in a
procedure is "save" attribute, so it is better for you to give initial
values for
the local variables in the execute line.

|
Pages: 1
Prev: Can I create header file dependent by gfortran
Next: Can I create header file dependent by gfortran