(j3.2006) Question about 29113
Wed Oct 1 23:01:19 EDT 2014
On Thu, 2014-10-02 at 10:01 +0900, Malcolm Cohen wrote:
> If you check the paper that introduced these, this facility was (approximately)
> intended to allow general memory allocators written in C to allocate memory for
> Fortran entities.
It took me a while to find the paper that introduced these. This
description isn't in the standard, and there's no reference to either
11-210r1 or MPI_ALLOC_MEM in the standard. Without some clues, the
fourth paragraph of FPTR is confusing. A note summarizing the goals set
forth in 11-210r1, in more generic terms than MPI_ALLOC_MEM, would be
> No clairvoyance is needed,
if you happen to have 11-210r1 or Malcolm's e-mail address handy...
> the sentence indeed means what it says, indeed you
> are not allowed to use "p3" to construct a pointer to ANY other Fortran entity
> whatsoever. Far from nonsense it is precisely what we intended.
It's not obvious why intending that is useful or helpful, or why not
prohibiting it is harmful.
If we really need this, it would be helpful to insert ", and is not
derived from [dependent upon?] the result of a reference to C_LOC" after
"storage sequence" to make it clear that p4 is describing a case
different from both p2 and p3, not a case that applies to both of them
since "the address of a storage sequence" could have resulted from
either of the scenarios described in p2 and p3.
Using only "is not the result of..." doesn't work because one might get
the address of an array element using C_LOC, send it to a C function,
which increments it, resulting in an address that's still the address of
an element of the same array, and then returns it to Fortran. Or one
might send the address of an interoperable structure to C, which then
returns the address of (an element of) a component of it....
Actually, this doesn't quite work either, because p2 doesn't say
anything about CPTR being related to the result of a reference to CLOC,
and p4 doesn't say "noninteroperable."
In any case, "in use by another Fortran entity" isn't quite what we
want, since thereby one cannot do the following (perhaps spread over
several scoping units):
call c_f_pointer ( cptr, fptr1 )
call c_f_pointer ( cptr, fptr2 )
if ( associated(fptr1,fptr2) ) ...
because the value of cptr in the second call is "in use" by fptr1.
Maybe "shall not be the address of a Fortran entity" would work.
Looking a bit more deeply at p3, why is FPTR required to be scalar?
This prevents dragging a pointer assocociated with a noninteroperable
array through a C function and thence into another Fortran subprogram.
Did we really intend to prohibit this? How about the case that the "C
function" is actually an interoperable Fortran subprogram?
> -----Original Message-----
> From: Van Snyder
> Date: ?? 26?9?25? 4:01
> To: j3
> Subject: (j3.2006) Question about 29113
> In the first edit in clause 9.9 in N1904 (DTS 29113), a paragraph is
> added to the description of the FPTR argument of C_F_POINTER. The final
> sentence is:
> "The storage sequence shall be large enough to contain the
> target object described by FPTR, shall not be in use by another
> Fortran entity, and shall satisfy any other processor-dependent
> requirements for association."
> What is the meaning of the middle part, viz. "shall not be in use by
> another Fortran entity"?
> Not the target of another pointer? That's nonsense.
> Not part of a pending I/O transfer? That's nonsense.
> What else?
> This appears at [445:27-446:1] in 14-007r2.
> Can we either delete this, or replace it with something that does not
> require clairvoyance to understand it?
> J3 mailing list
> J3 at mailman.j3-fortran.org
> This e-mail has been scanned for all viruses by Star.
More information about the J3