[J3] Question about C_F_Pointer

[Van Snyder]

On Mon, 2021-05-03 at 15:07 -0400, Vipul Parekh via J3 wrote:
> > Or maybe I've missed something and I'm unnecessarily doing things
> > the hard way.
> 
> Yes, both.
> 
> You've missed out on the other unlimited polymorphic type
> introduced starting Fortran 2018, TYPE(*).  This type is what you can
> consider if you are looking to "to pass Fortran objects through C
> code and thence onward to Fortran code".

Using TYPE(*) requires either a pointer or a SELECT TYPE construct.
That's just more code to get wrong and maintain or break during
maintenance. It's not much different from doing things the old "hard
way."

If a Fortran object is an actual argument to a procedure that has an
interoperable interface declaration, and the corresponding dummy
argument does not have the VALUE attribute, the "under the covers"
entity that gets passed to the procedure is a C pointer.

If the C part of the program eventually passes that pointer to an
interoparable Fortran subprogram, and the dummy argument does not have
the VALUE attribute, there should be no problem. But there is because
an interoperable subprogram is required to have interoperable
arguments. There seems to be no reason for this restriction.

Consider the degenerate case where there isn't actually a C
intermediary: A Fortran subprogram calls an interoperable Fortran
subprogram, the actual argument is neither polymorphic nor has a length
parameter, and the actual argument corresponds to a dummy argument that
does not have the VALUE attribute, there should be no problem. After
all, Fortran 77 actually worked.

If there is an intermediary C function that tries to "do something"
with a non-interoperable Fortran entity, by way of a pointer (formal
parameter defined with asterisk), it would cause what the C standard
causes "undefined behavior."

A Fortran program can cause a C function to do this anyway by using
C_LOC on the non-interoperable object, and passing it to a C program
whose Fortran interface declares the formal parameter to be of
type(C_Ptr) and have the VALUE attribute. This is not prohibited.

(The description of the argument to C_LOC seems a bit redundant. It
says the argument shall be a variable with interoperable type and type
parameters, an assumed-type variable, or a nonpolymorphic variable with
no length type parameter. I don't think there are any interoperable
types with length type parameters. An assumed type (not assumed class)
variable is not polymorphic. So it seems to be enough to say only that
the argument is nonpolymorphic and has no length type parameters.)

So the constraint against non-interoperable dummy arguments actually
has no value.


For example, if a Fortran program declares a quad precision REAL
variable (and the processor supports it), it cannot be an actual
argument  to an interoperable subprogram that corresponds to a dummy
argument declared void* (C_Ptr and VALUE in Fortran). But it can be
passed using C_Loc, provided the corresponding dummy argument is C_Ptr
and VALUE. If all the C function eventually does is invoke an
interoperable Fortran procedure that has a quad-precision dummy
argument that does not have the VALUE attribute, there should be no
problem. If the C function tries to "do something" by dereferencing the
pointer, it causes "undefined behavior."

There should be no problem passing non-interoperable actual arguments,
provided the corresponding dummy argument does not have the VALUE
attribute. So it shouldn't be prohibited. If the object is not
interoperable because it's polymorphic or has a length type parameter,
when the C pointer that is used to carry it through from Fortran to C
and back to Fortran arrives in Fortran again, the type and length are
not carried along. That's a problem for the receiving Fortran
procedure, not the standard. Instead of requiring the dummy argument to
be interoperable, it is sufficient to prohibit it to be polymorphic or
have a length type parameter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210503/30f5ae30/attachment.htm>