I'm replying to Van Snyder because one of his paragraphs makes me unsure
of what should happen in F95.
As in much of the previous discussion, I programmed on IBM machines back
in the 1960's where we overlayed COMMON and routines.
> This may be confusing because, although true, the passage you quote from
> the LF95 manual, is only half of the story. The important distinction is
> "can" instead of "does".
>
> Common variables are allowed to become undefined if no scoping unit that
> accesses the common block is in execution. So if the main program calls
> A and A calls B, and A and B declare the same common block, but don't give
> it the SAVE attribute, and it's not declared in the main program, the values
> defined in it by A and B remain defined until A returns to the main program.
> At that instant the processor is permitted to undefine the varables in the
> common block. It IS NOT allowed to undefine the common variables when B
> returns because A is still "in execution."
>
> If a variable becomes storage associated with another variable that has
> different type -- either by equivalence or common, assigning to one causes
> the other to become undefined, atleast in the sense that the value has a
> meaning defined by the standard.
>
> The same story holds for module variables.
I've left all of the above in, but know wonder if my understanding is
correct. I believe that in F95, any local variable declared with data,
either on the type declaration or in a DATA statement is "saved". What
happens with COMMON declared in BLOCK DATA routines? Are they assumed
declared at the highest level, or at teh level in which they first appear?
Regards, Paddy
***********************************************************************
"This electronic message and any attachments may contain privileged
and confidential information intended only for the use of the
addressees named above. If you are not the intended recipient of
this email, please delete the message and any attachment and advise
the sender. You are hereby notified that any use, dissemination,
distribution, reproduction of this email is prohibited.
If you have received the email in error, please notify TransGrid
immediately. Any views expressed in this email are those of the
individual sender except where the sender expressly and with
authority states them to be the views of TransGrid. TransGrid uses
virus scanning software but excludes any liability for viruses
contained in any attachment.
Please note the email address for TransGrid personnel is now
[log in to unmask]"
***********************************************************************
|