J3/14-140
To:        J3
From:      Van Snyder
Subject:   Interp concerning LOCK_TYPE and POINTER
Date: 2014 April 03
Reference: 14-138, 14-139

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

This paper ought not to be pursued as an interpretation if 14-138 is
adopted as a work item.

Assume LOCK_TYPE is accessible from ISO_Fortran_Env.

QUESTION 1:

The following type definition and variable declaration are permitted by
C1302:

  type :: One
    type(lock_type), pointer :: L
  end type One

  type(one), allocatable :: L1[*], L2[*]

Assuming L1 and L2 have been allocated, was it intended that the
following pointer assignment be prohibited?

  l1%l => l2%l

Was it intended that the following statement be prohibited?

  nullify ( l1%l )

QUESTION 2:

C1302 requires a named variable of LOCK_TYPE to be a coarray.  C526
requires a coarray to be allocatable or to have the SAVE attribute.

The following declaration is apparently prohibited because L4 is
not a coarray:

  type(lock_type), pointer :: L4

Was it intended that pointer components of type LOCK_TYPE be permitted,
but that named variables of type LOCK_TYPE with the POINTER attribute be
prohibited?

A named variable of type LOCK_TYPE is permitted to be an actual argument
in a reference to the function C_LOC from the intrinsic module
ISO_C_Binding.  Once one has the C address of a variable of type
LOCK_TYPE there is nothing that can be done with it because a variable
of type LOCK_TYPE cannot be a pointer, and therefore one cannot recover
a Fortran pointer from a C address using C_F_POINTER.

ANSWER 1:

It was not intended to prohibit a component of type LOCK_TYPE to be a
<data-pointer-object> or a <data-target> in a pointer assignment
statement.

It was not intended to prohibit a component of type LOCK_TYPE to be a
<pointer-object> in a NULLIFY statement.

Edits are provided to correct this.

ANSWER 2:

It was not intended to prohibit pointers of type LOCK_TYPE.  It was not
intended that if pointers of type LOCK_TYPE were to be permitted that
they would be prohibited in pointer-association contexts other than
allocation and deallocation.

EDITS:

In C1302 in subclause 13.8.2.16 LOCK_TYPE, after "coarray" insert "or a
pointer".

In C1303 in subclause 13.8.2.16 LOCK_TYPE, after "<allocate-object>"
insert "if it is not a pointer, as the <pointer-object> in a NULLIFY
statement, as a <data-pointer-object> or <data-target> in a pointer
assignment statement, as an actual argument in a reference to a
procedure with explicit interface if it is a pointer and the
corresponding dummy argument has INTENT(OUT)".

In C1304 in subclause 13.8.2.16 LOCK_TYPE, after "<allocate-object>"
insert "if it is not a pointer, as the <pointer-object> in a NULLIFY
statement, as a <data-pointer-object> or <data-target> in a pointer
assignment statement, as an actual argument in a reference to a
procedure with explicit interface if it is a pointer and the
corresponding dummy argument has INTENT(OUT)".

After this correction, the only circumstance in which "variable
definition context" appears, and does not apply only to nonpointers, is
in C1293 in subclause 12.7 "Pure procedures."

If C1293 were revised to include "in a pointer association context",
items(2) and (3) in the list in subclause 16.6.7 "Variable definition
context" could be removed, and item (12) could explicitly apply in the
case that the actual argument and dummy argument are not both pointers.

If the list in subclause 16.6.7 "Variable definition context" were
thereby revised, as advocated in 14-139, C1303 and C1304 could be
substantially simplified.

SUBMITTED BY: Van Snyder

HISTORY: m204  13-xxx    Submitted

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