To: J3                                                     J3/20-164
From: Jon Steidel
Subject: Interp 18-007
Date: 2020-October-14

Interp 18-007 failed the J3 letter ballot.  This version contains
updated edits to address the concerns raised in ballot comments.


_______________________________________________________________

NUMBER: F18/007
TITLE: Problems with C_FUNLOC and C_F_PROCPOINTER being PURE
KEYWORDS: C_FUNLOC, C_F_PROCPOINTER, ISO_C_BINDING
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTIONS:

1) Regarding C_FUNLOC (X),

In 15.7 Pure procedures, constraint C1590 is:

"C1590 The specification-part of a pure subprogram shall specify
that all its dummy procedures are pure."

In 15.5.2.9 Actual arguments associated with dummy procedure entities,
the first paragraph says

"If the interface of a dummy procedure is explicit, its
characteristics as a procedure (15.3.1) shall be the same as those
of its effective argument, except that a pure effective argument
may be associated with a dummy argument that is not pure and an
elemental intrinsic actual procedure may be associated with a dummy
procedure (which cannot be elemental)."

If C_FUNLOC is PURE, then these together imply that the actual
argument, X, has to be a PURE procedure. This is not stated in the
specification of this function in 18.2.3.5. This has the effect of
limiting the uses of C_FUNLOC compared to the specification in Fortran
2008. This is not indicated in 4.3.3 Fortran 2008 compatibility. Was
this an intentional change, or was making C_FUNLOC PURE a mistake?

2) Regarding C_F_PROCPOINTER (CPTR, FPTR), a similar argument to that
above implies that the INTENT(OUT) procedure pointer, FPTR, is a PURE
procedure. However, there is no stated requirement that the input
argument CPTR be PURE, and indeed there is no specification of what
that even means if CPTR is a pointer to an interoperable C function.
This suggests that C_F_PROCPOINTER provides a backdoor allowing an
impure procedure to appear to be pure, invalidating the assumptions
that are associated with a pure procedure. Was making C_F_PROCPOINTER
a PURE a mistake?

ANSWER:

1) Making C_F_PROCPOINTER PURE was a mistake. Edits are included to
correct this error.

2) It was not an error to make C_FUNLOC PURE. Constraint C1590 does
not apply to C_FUNLOC as it is an intrinsic module procedure, and
as such is not defined by a subprogram. If a PURE procedure invokes
C_FUNLOC, then the argument to C_FUNLOC must be a PURE procedure.
However if an IMPURE procedure invokes C_FUNLOC, the actual
argument to C_FUNLOC need not be a PURE procedure. An edit is
provided to clarify this.

EDITS to 18-007r1:

[469:26-27] In 18.2.3 Procedures in the module, 18.2.3.1 General,
second sentence, change "C_F_POINTER subroutine is" to "C_F_POINTER
and C_F_PROCPOINTER subroutines are".

Making the whole sentence read

"The C_F_POINTER and C_F_PROCPOINTER subroutines are impure; all
other procedures in the module are pure."

[472:16] In 18.2.3.4 C_F_PROCPOINTER (CPTR, FPTR), Class paragraph,
Change "Pure subroutine" to "Subroutine".

[472:30] In 18.2.3.5 C_FUNLOC (x) after "object." add
"If C_FUNLOC is referenced in a pure procedure, X shall be a pure
procedure; otherwise it may be impure."

SUBMITTED BY: Bill Long

HISTORY: 19-114 m218 Submitted
19-114r1 m218 Revised draft
19-114r2 m218 Passed as amended by J3 meeting
19-228 m220 Failed J3 letter ballot #35
20-xxx m222 Repair edits to satisfy objections raised in letter
       ballot.