Scope of module variables

[Erik Toussaint]

Hello,

I have a question about the scope of module variables. Consider the
following source code. When compiled (with gfortran) and run, it prints
the value 2 on screen. Does the standard guarantee this behaviour?

module mod1
integer intvar1
end

subroutine sub1
use mod1
intvar1 = 2
end

subroutine sub2
use mod1
print *, intvar1
end

program prog1
call sub1
call sub2
end

I would think that after returning from the first subroutine, intvar1
becomes undefined (and in fact stays undefined for the remainder of the
program), so the second subroutine cannot count on intvar1 having a
defined value, even though both procedures use the module.

Is my reasoning correct? Would adding the following use statement to the
main program alter this, causing intvar1 to stay defined after exiting sub1?

use mod1, only:

(In fact I started thinking about this when reading paragraph 7.10 from
'fortran 95/2003 explained' by Metcalf, Reid, and Cohen, and its
discussion of the use of an empty only-list in a use statement.)

Erik.

[Tobias Burnus]

On 11/03/2010 04:23 PM, Erik Toussaint wrote:
> I have a question about the scope of module variables. Consider the
> following source code. When compiled (with gfortran) and run, it prints
> the value 2 on screen. Does the standard guarantee this behaviour?

...]

> I would think that after returning from the first subroutine, intvar1
> becomes undefined (and in fact stays undefined for the remainder of the
> program), so the second subroutine cannot count on intvar1 having a
> defined value, even though both procedures use the module.

I think in practice it is very likely to work. If I recall correctly, in
terms of the Fortran 90 to 2003 standard, it is not completely clear
until when the module is in use - thus it is implementation defined
whether it works or not.

Hence, to have a conforming Fortran 90 to 2003 program, you should
declare the variable with a SAVE attribute.

In Fortran 2008, module variables have implicitly the save attribute
thus the program seems to be a valid Fortran 2008 program.

F2008's "5.3.16 SAVE attribute" has: "A variable, common block, or
procedure pointer declared in the scoping unit of a main program,
module, or submodule implicitly has the SAVE attribute, which may be
confirmed by explicit specification."

Tobias

[Richard Maine]

Erik Toussaint <us...@example.net.invalid> wrote:

> I have a question about the scope of module variables. Consider the
> following source code. When compiled (with gfortran) and run, it prints
> the value 2 on screen. Does the standard guarantee this behaviour?

[code elided]

No, the standard does not guarantee it - at least not in f90/f95/f2003.
I have heard that f2008 does, but I haven't checked.

> I would think that after returning from the first subroutine, intvar1
> becomes undefined (and in fact stays undefined for the remainder of the
> program), so the second subroutine cannot count on intvar1 having a
> defined value, even though both procedures use the module.

> Is my reasoning correct? Would adding the following use statement to the
> main program alter this, causing intvar1 to stay defined after exiting sub1?

Yes, and yes.

As an aside, "scope" is note the right term for what you are asking
about. Scope just has to do with *WHERE* you can access the variable -
not with *WHEN* it is defined.

The standard doesn't formally have a single term for the concept you
want, but "lifetime" is often used inforally.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Erik Toussaint]

On 3-11-2010 16:56, Richard Maine wrote:
> Erik Toussaint<us...@example.net.invalid> wrote:
>
>> I have a question about the scope of module variables. Consider the
>> following source code. When compiled (with gfortran) and run, it prints
>> the value 2 on screen. Does the standard guarantee this behaviour?
>
> [code elided]
>
> No, the standard does not guarantee it - at least not in f90/f95/f2003.
> I have heard that f2008 does, but I haven't checked.
>
>> I would think that after returning from the first subroutine, intvar1
>> becomes undefined (and in fact stays undefined for the remainder of the
>> program), so the second subroutine cannot count on intvar1 having a
>> defined value, even though both procedures use the module.
>
>> Is my reasoning correct? Would adding the following use statement to the
>> main program alter this, causing intvar1 to stay defined after exiting sub1?
>
> Yes, and yes.

Thanks, Richard and Tobias, for your answers.
Clears up things for me.

> As an aside, "scope" is note the right term for what you are asking
> about. Scope just has to do with *WHERE* you can access the variable -
> not with *WHEN* it is defined.
>
> The standard doesn't formally have a single term for the concept you
> want, but "lifetime" is often used inforally.
>

Right, I thought so myself, but unfortunately the thought didn't come to
me until after I clicked the 'send' button. 'Lifetime' was indeed the
same term that popped into my head.

Erik.

[James Van Buskirk]

"Erik Toussaint" <us...@example.net.invalid> wrote in message
news:4cd19c03$0$777$58c7...@news.kabelfoon.nl...

And that's why at least the older standards didn't allow you to put
instances of user-defined types with default initialization (or, I
think ALLOCATABLE variables) in a module unless they had the SAVE
attribute: because to be consistent with other usage of these objects
the compiler would have to generate code to determine when they ended
their lifetimes so they could be default-initialized or deallocated.

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

[glen herrmannsfeldt]

Erik Toussaint <us...@example.net.invalid> wrote:

> I have a question about the scope of module variables. Consider the
> following source code. When compiled (with gfortran) and run, it prints
> the value 2 on screen. Does the standard guarantee this behaviour?

I believe that this is similar to a case that has been
discussed regarding COMMON. In the COMMON case, one reason
for the data in such a COMMON block losing its values had to
do with overlays. Now, as far as I know the standard doesn't
mention overlay, but it was often used in the days past, and
one would expect standard conforming programs to work.

I don't know any restriction on using module variables
with overlays, so one should consider that case.

Standard or not, it is likely to work if you don't: use overlays,
place the module variables in an overlay, and actually overlay
them with something else.

> module mod1
> integer intvar1
> end

> subroutine sub1
> use mod1
> intvar1 = 2
> end

> subroutine sub2
> use mod1
> print *, intvar1
> end

> program prog1
> call sub1
> call sub2
> end

(snip)

-- glen