To: J3 Members J3/16-144 From: Van Snyder Subject: Comments on or concerning Clause 16 Reference: 16-007 Date: 2016 January 25 1. Edits ======== [3:17 1.3.8.1] After "12.5.2" insert ", 16.5.1.2". [3:25 1.3.8.3] Before "16.5.1.4" insert "12.4.3.4,". [3:44 1.3.8.9] After "11.2.2" insert ", 16.5.1.3". [283:1- NOTE 11.12+] Insert a note: "NOTE 11.12a Use association is further explained in 16.5.1.3." [290:6+ 12.4.3.4 R1211-] Insert a sentence of initial waffle, so we have a place for a cross reference to 16.5.1.4, where important material concerning host association appears: "An IMPORT statement causes names to be accessible by host association (16.5.1.4)." [303:1- NOTE 12.24+] Insert a note: "NOTE 12.24a Argument association is further explained in 16.5.1.2." [490:13+ 16.4p1+] Insert a paragraph: "An identifier of a statement or construct entity has a scope of the statement or construct. Statement or construct entities are not accessible outside their statement or construct." {Compare the above to [492:36].} [492:penultimate line NOTE 16.5] Before "in an ASYNCHRONOUS..." insert "only". [493:9 16.5.1.4p5] After "module" insert "where its type and type parameters are established or accessible". [493:10 16.5.1.4p5] Append a sentence: "The type and type parameters of a function are accessible in a module if they are established in that module or accessed by use association from a module where its type and type parameters are accessible." [493:13 16.5.1.4p6] After "module" insert "where its intrinsic nature is established or accessible". [493:14 16.5.1.4p6] Append a sentence: "The intrinsic nature of a function is accessible in a module if it is established in that module or accessed by use association from a module where its intrinsic nature is accessible." [495:0+3 NOTE 16.9] Replace "were used" with "appear". [495:13 16.5.2.2p1 ] Append a sentence: "An action that causes a pointer's association status to become undefined does not imply that it was previously defined. An action that causes a pointer's association status to become defined does not imply that it was previously undefined. An action that causes a pointer to become associated does not imply that the pointer was previously disassociated. An action that causes a pointer to become disassociated does not imply that the pointer was previously associated." {Compare to 16.6.1p1 at [501:4-6] where a similar description concerning the definition status of variables was apparently considered to be important.} [495:14- NOTE 16.10 last line] Replace "pointer" with "pointer's association status to become undefined because its". [496:31 16.5.2.5p1(8)] After "instance of" insert "the target of". {Compare to 16.6.6p1(23) at [503:28] where "target of" was apparently considered to be important.} [497:32 16.5.2.7p1] Before "defined" insert "or become". [498:9-10 16.5.3.2p1] After "numeric storage unit" insert "(13.9.2.19)". After "character storage unit" insert "(13.9.2.5)". After "file storage unit" insert "(13.9.2.10)". [498:35+ 16.5.3.2p4+] Insert a NOTE "NOTE 16.10a Different storage units might be the same size." [500:27 16.5.5p5] Insert a list item: "o If the associating entity is polymorphic and the pre-existing entity is allocatable and not allocated or a pointer that is disassociated, the dynamic type of the associating entity is its declared type." {This is important for EXTENDS_TYPE_OF and SAME_TYPE_AS.} [500:31 16.5.5p5] Append a sentence: "If the association is argument association the lower bound of each dimension of the associating entity is one and the upper bound is one less than the extent in that dimension of the pre-existing entity." [501:13 16.6.1p6+] Insert a paragraph: "A subobject might be defined even if the object is defined." [502:2 16.6.4p1] Replace "All other variables" with "Variables other than those that are always defined or initially defined". [502:16 16.6.5p1(6)] Delete either "argument" or "data object". {We usually say "dummy argument" or "dummy data object" but not "dummy argument data object".} [502:24+ 16.6.5p1(9)+] Insert a list item: "(8a) Execution of a wait operation (9.7.1) corresponding to an asynchronous input statement causes the input list items or variables in the namelist group for which input is provided to become defined." {16.6.6p1(18) at [505:11-14] says they become undefined when the input statement begins execution. Presumably, they do become defined, but we don't say when.} [502:35 16.6.5p1(12)] Replace "an unspecified" with "a nonpointer unspecified". After "storage units" insert "of the same dynamic type and with the same type parameter values". [503:6 16.6.5p1(20)] Replace "array" with "object" {To cover the case of zero-length strings (and maybe derived-type objects that have no components and no length parameters).} [503:12 16.6.5p1(21)] Replace "automatic" with "nonsaved local". {But do we need this list item? According to 16.6.2, zero-size arrays and zero-length strings are always defined.} [504:5 16.6.6p1(3)(b)] Replace "unsaved variables in a" with "variables in an unsaved". {It's common blocks, not the variables in them, that get the SAVE attribute specified.} [504:10+ 16.6.6p1(4)+] Insert a list item: "(4a) When an end-of-record condition occurs during execution of a nonadvancing input statement and the pad mode is NO, list items for which corresponding edit descriptors require more characters than the record contains become undefined." {This is the answer proposed in an interp presented at this meeting. Maybe the interp should just be edits to 9.11.4p1(1)(b). 9.11.4p1(1)(b) just says "the input list item becomes undefined." It doesn't say which one or ones. Nothing appears in 16.6.6 to address that undefinition.} [505:31 16.6.6p1(24)] After "assignment" insert "to a variable". [505:33+ 16.6.6p1(24)+] Insert a list item: "(24a) Execution of an intrinsic assignment to a variable that has subobjects of type C_PTR or C_FUNPTR from the intrinsic module ISO_C_BINDING in which the variable and are on different images causes those subobjects to become undefined." [506:15+ 16.6.7p1(11)+] Insert a list item: "(11a) a subobject of a that is a selector in a SELECT TYPE or ASSOCIATE construct if the corresponding subobject of the associate name appears in a variable definition context;" 2. Questions without edits ========================== Some of these might need edits. [496:26 16.5.2.5p1(2)] A pointer's association status becomes undefined if the pointer is pointer assigned to a target on a different image. In light of C726, is this possible? Might it happen by derived-type assignment of objects that have pointer components? [496:31 16.5.2.5p1(5)] How can an object without the TARGET attribute be pointer associated with anything, let alone the TO argument of the MOVE_ALLOC subroutine? [498:21 16.5.3.2p2(5)] Should "length" be inserted before "type parameters"? [505:20-21 16.6.6p1(21)] How can an object without the TARGET attribute be pointer associated with anything?