To: J3 J3/21-124 From: Jon Steidel & Bill Long Subject: Interp F18/007 Date: 2021-February-28 References: J3/20-164 Interp F18/007 failed its letter ballot. This version contains updated edits to address the concerns raised in ballot comments. This paper replaces J3/20-164 that was deferred from M222. ---------------------------------------------------------------------- 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 PURE a mistake? ANSWER: 1) It was not an error to make C_FUNLOC pure in principle. But if a reference to C_FUNLOC appears in a pure procedure, its argument should have been required to be pure. It is noted that constraint C1590 does not apply to C_FUNLOC as it is a procedure from an intrinsic module, and as such is not defined by a subprogram. The only question is whether its argument is required to be pure, and in what circumstances. 2) Making C_F_PROCPOINTER pure was a mistake. Edits are included to correct these errors. EDITS to 18-007r1: [325:8+] In 15.7 Pure Procedures, following constraint C1599, add a new constraint: "C1599a A reference to the function C_FUNLOC from the intrinsic module ISO_C_BINDING shall not appear in a pure subprogram if its argument is impure." [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". 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 21-xxx m223 Repair edits to satisfy objections raised in letter ballot. ----------------------------------------------------------------------