J3/14-241r1 To: J3 From: Van Snyder Subject: Interpretation about pointer subobjects of type LOCK_TYPE Date: 2014 October 03 Reference: 10-007r1, 14-139r2, 14-172, 14-215 part 3.4, 14-231/N2027 14-172 was submitted at meeting 204 as a work item, was moved by Long, seconded by Lionel, and accepted with unanimous consent. Then it was decided that its application to LOCK_TYPE ought to be processed as an interpretation (see 14-215 part 3.4). Its edit to 14-007r1 was not included in 14-007r2, but its edit to 14-130, concerning EVENT_TYPE, was included in 14-231/N2027 (draft of TS 18508). 14-139r3, which covers related ground, was accepted and incorporated into 14-007r2. The changes therein that are related to the distinction between pointer association and variable association are included here. Whether they should be included in a corrigendum can be decided in due course. ------------------------------------------------------------------------ NUMBER: TBD TITLE: Definition of objects of type LOCK_TYPE with pointer subobjects KEYWORD: pointer subobject, variable definition context, LOCK_TYPE DEFECT TYPE: Error STATUS: J3 consideration in progress QUESTION: Does the following conform to the Fortran 2008 standard? type :: T type(lock_type), pointer :: P = NULL() end type T type(t), parameter :: N = t(null()) type(t) :: V type(lock_type), target :: L 1 nullify ( v%p ) 2 v%p => l 3 v = n ANSWER: Constraint C1303 prohibits a variable of type LOCK_TYPE from appearing in a variable definition context, with a few exceptions that do not include statements 1 and 2. Subclause 16.6.7 specifies that the appearance of a variable as a in a , or as a or in a , is a variable association context. Therefore statements 1 and 2 do not conform to the Fortran 2008 standard. The appearance of a in a , or of a or in a , are pointer association contexts, and are listed as such in subclause 16.6.8; they ought not to be listed as variable definition contexts in subclause 16.6.7. {The above proposition was advocated in 14-139r3, accepted at meeting 204, and incorporated into 14-007r2. Therefore, statements 1 and 2 will conform to the next revision of the Fortran standard. Whether statements 1 and 2 ought to be included in the present question can be decided in due course.} Constraint C1304 prohibits a variable with a subobject of type LOCK_TYPE from appearing in a variable definition context, with a few exceptions that do not include statement 3. Therefore statement 3 does not conform to the Fortran 2008 standard. {The proposition that the prohibition should only apply to variables that have nonpointer subobjects of the type EVENT_TYPE being developed in TS 18508 was accepted, and incorporated into 14-231/N2027.} Statements 1-3 are harmless, and ought to be permitted. Edits are provided to correct this. EDITS: [399:22 C1304] Insert "nonpointer" before "subobject". {A change parallel to this, concerning EVENT_TYPE, is already incorporated in 14-231/N2027.} EDITS already applied in 14-007r2: [312:33+ C1283(1)+] Insert a list item "(1a) in a pointer association context (16.6.8)," {This is a knock-on effect due to deleting pointer association contexts from the list of variable definition contexts. It recovers items (2), (3) and (12) from 16.6.7p1, which are deleted below.} [313:1-2 C1283(5)] Delete "with INTENT(OUT) or INTENT(INOUT)" from item (6) because it is covered by 16.6.7p1(12). [456:44-45 16.6.7p1(2-3)] Delete list items (2) and (3) because they are not variable definition contexts, and do not apply to nonpointer variables. [445:11 16.6.7p1(12)] Append "is not a pointer and" after "dummy argument", because an actual argument pointer corresponding to a dummy argument pointer is not a variable definition context, and doesn't apply to nonpointer variables. SUBMITTED BY: Van Snyder HISTORY: m205 14-nnn Submitted ----------------------------------------------------------------------