07-229 To: J3 From: Van Snyder Subject: Allocation of allocatable variables Date: 2007 May 10 Introduction ------------ "6.3.1.1 Allocation of allocatable variables" is turgid, and discusses both more and less than advertised. "Allocation status" could be defined in a new subclause about allocatable variables in 2.4, say after 2.4.7. Events that change allocation status could be described somewhere in clause 16, say between "16.6.6 Events that cause variables to become undefined" and "16.6.7 Variable definition context." Edits do the former, but not the latter, as the discussion of events that cause the allocation status to become unallocated are entangled with similar events that do not cause the allocation status to become unallocated, and the discussion of other events that are a consequence of deallocation. Edits ----- [22:15-20] Editor: Replace the paragraph: "A pointer may have an association status of associated, disassociated or undefined (\ref{D16:Pointer association status}). It becomes associated as described in 16.5.2.2.1. It becomes disassociated as described in 16.5.2.2.2. It becomes undefined as described in 16.5.2.2.3." [22:22] Editor: Replace "extents" by "bounds" and replace "the pointer" by "it". [22:23+] Editor: Insert a new subclause: "2.4.7a Allocatable variables An <> is a variable that has the ALLOCATABLE attribute. The allocation status of an allocatable variable is either <> or <>. An allocatable variable becomes allocated as described in 6.3.1.1. It becomes unallocated as described in 6.3.3.1. An unallocated allocatable variable shall neither be referenced nor defined. If an allocatable variable is an array, the rank is declared but the bounds are determined when it is allocated. " Not being proposed at this time ------------------------------- [127:7+] 6.3.0a Allocatable variables An allocatable variable becomes allocated if it is allocated by an ALLOCATE statement, if it is allocated during intrinsic assignment (7.2.1.3) or if it is given the allocated status by the intrinsic procedure MOVE_ALLOC (13.7.125). An allocatable variable has an allocation status of unallocated at the beginning of execution of a program. An unsaved allocatable local variable of a procedure has an allocation status of unallocated at the beginning of each invocation of the procedure. An unsaved local variable of a BLOCK construct has an allocation status of unallocated at the beginning of each execution of the construct. When an object of derived type is allocated, any allocatable ultimate components have an allocation status of unallocated. An allocatable variable becomes unallocated if it is deallocated by a DEALLOCATE statement, if it is deallocated during intrinsic assignment (7.2.1.3), if it is given the allocated status by the intrinsic procedure MOVE_ALLOC (13.7.125), or if it is deallocated by events described in 6.3.3.1. An allocatable component of an object of derived type can become allocated or unallocated by the evaluation of a structure constructor (4.5.10). When the allocation status of an allocatable variable changes, the allocation status of any associated variable changes accordingly. An allocated allocatable variable may be referenced, defined or deallocated. The intrinsic function ALLOCATED (13.7.10) returns true if its argument is an allocated allocatable variable. An unallocated allocatable variable shall not be referenced or defined. It shall not be the actual argument associated with a nonallocatable dummy argument in a procedure reference other than a specification inquiry that is not an array inquiry, not a reference to LEN if the character length is deferred, and not a type parameter inquiry if the type parameter is deferred. The intrinsic function ALLOCATED (13.7.10) returns false if its argument is an unallocated allocatable variable. " [129:2+] Editor: Move [130:1-2 and [130:6-15] here. [129:13+] Editor: Move [129:28-30] and Note 6.19 to here. Then insert a new paragraph: "Allocation of an allocatable variable causes an error condition in the ALLOCATE statement." [129:14-] Editor: Insert the following: "6.3.1.1 Allocation of entities Execution of an ALLOCATE statement allocates some or all of the specified s. If no error condition occurs it allocates all of the specified s. \begin{note} Note 6.17a After execution of an ALLOCATE statement in which an error condition occurs the intrinsic function ALLOCATED (13.7.10) can be used to determine which variables are allocated. \end{note} " [Move 129:3-6 to here, and replace "If" by "When an allocate statement is executed, if".] [Move 129:25-27] to here. [Move 129:11-13 to here. Then insert the following paragraph.] "When allocation establishes the dynamic type of an allocatable variable, the dynamic type of any associated allocatable variable is established to be that type. When execution of an ALLOCATE statement establishes the value of a type parameter of an allocatable variable, the corresponding type parameter of any associated allocatable variable is established to have the same value. Subsequent redefinition or undefinition of any expression in or does not affect the dynamic type or type parameters." [130:5+] Editor: Insert the following paragraph: "When execution of an ALLOCATE statement establishes the bounds of an allocatable array or co-bounds of an allocatable co-array, any associated variable is established to have the same bounds and co-bounds." [130:16-131:2] Editor: Delete. [131:14-16] This is a weird place for this paragraph. It belongs in clause 12 somewhere, preferably in a not-yet-created "Function result variable" subclause, perhaps between 12.5.2 and 12.5.3 at [322:1-]. Questions without answers or edits ---------------------------------- If SOURCE= appears in an ALLOCATE statement, the value of "becomes" that of (see [130:6-10]). Is this "as if" by intrinsic assignment? If the allocated object is of a derived type with allocatable components, it seems necessary to operate "as if" by intrinsic assignment. Does this need an interp? \end{document}