J3/00-335

Date:     12 Dec 2000
To:       J3
From:     Richard Maine
Subject:  C_PTR (issue 151)

DISCUSSION:

Issue 151 asks about C_PTRs and procedure pointers to module
procedures.  The same question comes up in conjunction with
Fortran procedure pointers.  After consultation with /data,
the the following interpretation was proposed.

When a module "goes out of scope" because of execution of a
RETURN or END statement, unsaved module data objects become
undefined as described in 14.7.6(3).  Consequently the association
status of pointers to those data objects becomes undefined as
described in 14.6.2.1.3.

However, this does not apply to procedure pointers.  The target
of a procedure pointer is not a data object; it therefore has
no definition status.  There is no text in the standard saying
that a procedure pointer to a module procedure becomes undefined
when the module "goes out of scope".  Therefore it does not.
Furthermore, this is the desired state of affairs.

This question then arises of what happens to unsaved module
variables if a module procedure is invoked while the module is
"out of scope".  Before procedure pointers and C interop there
was no way for this to happen, but now it can.

The interpretation suggested by /data is that a module inherently
references itself.  Therefore, if a module procedure is invoked while
the module is "out of scope", the module "comes into scope" just as it
would if some other procedure that USEd the module were invoked.
Item 14.7.6(3)(e) refers to the module being "referenced" by a
scoping unit.  This section does not say that the reference has to
be in the form of a USE statement.  That choice of wording was
intentional, in order to cover such cases as referencing via
host association (as in an internal procedure whose host USEs
the module).  Similarly, a module procedure references its own
module by host association.

EDITS:

[265:26-41] Delete issue 151

[363:26+]  Add note (regular note - not a J3 one)

  "A module subprogram inherently references the module that is
   its host.  Therefore, for processors that keep track of when
   modules are in use, a module is in use whenever any procedure
   in the module is active, even if no other active scoping units
   reference the module; this situation can arise if a module
   procedure is invoked via a procedure pointer or a companion
   processor."

{Unrelated fix in 5.1.2.7.  Its list of ways a pointer can become
associated is incomplete and unnecessary.  Also, it is required
that the pointer currently be associated; it is not sufficient
for it to have become associated at some previous time.}

[77:23-24] Replace "unless...it becomes" -> "unless it is".