J3/14-169 To: J3 From: Van Snyder Subject: Unlimited polymorphic and LOCK_TYPE Date: 2014 June 08 Reference: 14-165 1. Introduction =============== If protected types, as described in 14-165, are provided, this paper would be largely irrelevant. If one were to extend a type that does not involve type LOCK_TYPE, and add a component of type LOCK_TYPE, the processor could not see the LOCK_TYPE component in references to a polymorphic variable of the base type. Constraints against tampering with objects or subobjects of type LOCK_TYPE would then be powerless. Constraint C438 prevents this extension, but does not completely protect lock variables against unauthorized tampering. It doesn't (and cannot) prevent allocating an unlimited polymorphic object with a that specifies type LOCK_TYPE or a type that contains a LOCK_TYPE component, or using a of such a type. Subclause 13.8.2.16 doesn't actually say that lock variables are not definable except by executing LOCK and UNLOCK statements. It gives a false sense of security by constraining against their appearance in variable-definition contexts. Straw vote: Do we want to 1) leave things as they are, 2) impose a run-time prohibition against meddling with lock variables by saying in subclause 13.8.2.16 that they're not definable except by executing LOCK and UNLOCK statements, 3) constrain against unlimited polymorphic objects having dynamic types involving LOCK_TYPE?, or 4) Both 2) and 3), because otherwise there's still a loophole involving C_LOC and C_F_POINTER. {Outcomes 3 and 4 compromises the principle that unlimited polymorphic means "unlimited."} 2. Edits to 14-007r1 assuming we only want a runtime prohibition against meddling ================================================================ [402:18 13.8.2.16p2] Before "A lock variable" insert "A lock variable is not definable except by executing a LOCK or UNLOCK statement." 3. Edits 14-007r1 to constrain against unlimited polymorphic with dynamic type involving LOCK_TYPE ================================================================= [6:19+ 1.3.35.2+] Insert a definition "1.3.33.2a potential subobject component a nonpointer component, or a potential subobject component of a nonpointer component" [129:9-10] Replace C643: "C643 (R626) The declared type of shall not be C_PTR or C_FUNPTR if an is a coarray. {The prohibitions in the current C643 against copying lock variables during allocation reappear below in revisions of C1303 and C1304.} "C643a (R626) The declared type of shall not be LOCK_TYPE or have a potential subobject component of type LOCK_TYPE, and shall not specify LOCK_TYPE or a type that has a potential subobject component of type LOCK_TYPE, if any is unlimited polymorphic." {or maybe} "C643a (R626) Executing an ALLOCATE statement shall not cause an unlimited polymorphic object to have a subobject of type LOCK_TYPE, or its dynamic type to become LOCK_TYPE." [155:11+ 7.2.1.2p1(1)+] Insert a list item "(1') If the variable is unlimited polymorphic, shall not be of a type LOCK_TYPE or have a subobject of a type LOCK_TYPE." [160:10+ C716+] Insert a constraint: "C716a (R733) If is unlimited polymorphic, shall not be of type LOCK_TYPE or have a subobject of type LOCK_TYPE." [402:18 13.8.2.16p2] Before "A lock variable" insert "A lock variable is not definable except by executing a LOCK or UNLOCK statement." {Wearing both a belt and suspenders helps prevent getting caught with your pants down.} [402:25 C1303] To be parallel to how copying objects of type EVENT_TYPE is prevented in TS 18508, replace "" with " in an ALLOCATE statement that does not have a SOURCE= specifier, an in a DEALLOCATE statement". [402:28 C1304] To be parallel to how copying variables that have subobjects of type EVENT_TYPE is prevented in TS 18508, replace "" with " in an ALLOCATE statement that does not have a SOURCE= specifier, an in a DEALLOCATE statement,". [402:29+ C1304+] Insert a constraint "C1305 A variable of type LOCK_TYPE, or that has a subobject of type LOCK_TYPE, shall not be an actual argument that corresponds to an unlimited polymorphic dummy argument."