J3/14-164
To:      J3
From:    Van Snyder
Subject: Interp concerning LOCK_TYPE and unlimited polymorphism
Date: 2014 May 30

----------------------------------------------------------------------

NUMBER: TBD
TITLE: LOCK_TYPE and unlimited polymorphic
KEYWORD: LOCK_TYPE, unlimited polymorphic
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTIONS:

Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is
available.

1. Is allocation of C permitted?

  class(*), pointer :: C
  type(lock_type), intent(in) :: L[*]

  allocate ( C, source=L )

2. Is allocation of C permitted?

  class(*), pointer :: C

  allocate ( LOCK_TYPE :: C )

3. Is pointer assignment to C permitted?

  class(*), pointer :: C
  type(lock_type), intent(in), target :: L[*]

  c => L

ANSWER:

Both allocations, and the pointer assignment, are permitted.

These would compromise protection of objects of type LOCK_TYPE, and
should have been prohibited.

Edits are provided to correct these mistakes.

EDITS:

After definition 1.3.33.2 "parent component", introduce a definition

"1.3.33.2a potential subobject component
   a nonpointer component, or a potential subobject component of a
   nonpointer component"

After constraint C643 in subclause 6.7.1.1, insert a constraint:

"C643a (R636) If any <allocate-object> is unlimited polymorphic,
        <type-spec> shall not specify LOCK_TYPE or a type that has a
        potential subobject component of type LOCK_TYPE, and the
        declared type of <source-expr> shall not be LOCK_TYPE or a type
        that has a potential subobject component of type LOCK_TYPE."

After constraint C715 in subclause 7.2.2.2, insert a constraint:

"C715a (R733) If  <data-pointer-object> is unlimited polymorphic, the
       declared type of <data-target> shall not be a LOCK_TYPE, nor
       shall it have a potential subobject component of type LOCK_TYPE."

SUBMITTED BY: Van Snyder

HISTORY: m204  13-xxx    F08/xxxx  Submitted

----------------------------------------------------------------------