(j3.2006) automatically deallocating unallocated allocatable variables
Sun Jan 9 23:51:29 EST 2011
On 1/8/11 1:48 AM, Robert Corbett wrote:
> The citations given here are for 10-007r1.
> Paragraphs 2 and 3 of Clause 184.108.40.206 [130:24-27] state
> When the execution of a procedure is terminated by execution of
> a RETURN or END statement, an unsaved allocatable local variable
> of the procedure retains its allocation and definition status if
> it is a function result variable or a subobject thereof;
> otherwise, it is deallocated.
> When a BLOCK construct terminates, an unsaved allocatable local
> variable of the construct is deallocated.
In both cases, I think the intent is "clearly" that the variable is
deallocated only if it was allocated at the indicated point. Some
wording improvement might be in order. I don't know of any
implementation that gets this wrong.
> Paragraph 10 of Clause 220.127.116.11 [131:10] states
> The effect of automatic deallocation is the same as that of a
> DEALLOCATE statement without a /dealloc-opt-list/.
> Paragraph 1 of Clause 6,7,3,2 [130:21] states
> Deallocating an unallocated allocatable variable causes an
> error condition in the DEALLOCATE statement.
> Paragraph 3 of Clause 18.104.22.168 [130:15-17] states
> If an error condition occurs during execution of a DEALLOCATE
> statement that does not contain the STAT= specifier, error
> termination is initiated.
> Taken together, these statements say that if an unsaved allocatable
> local variable (with the exception of a function result variable in
> the case of a procedure) is unallocated at the end of execution of
> a procedure or a BLOCK construct, error termination is initiated.
> Is this intended?
> If a DEALLOCATE statement contains an ERRMSG= specifier but not a
> STAT= specifier, error termination is initiated whenever the processor
> would assign a value to the /errmsg-variable/. I suppose the effect
> of the assignment might be detected if the /errmsg-variable/ has the
> VOLATILE sttribute.
> Robert Corbett
> J3 mailing list
> J3 at j3-fortran.org
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
More information about the J3