[J3] Question about C_F_Pointer

[Malcolm Cohen]

I note that this seems to be a new feature request for F202y. Or rather, several new feature requests.

 

I further note that the functionality as described seems to be available already.

 

(Feature one)

 

> You can't just use pointer assignment if what's really there is an array because you can't specify the bounds during pointer assignment.

 

Except that as you note later, you already can except in one specific case.

 

> It's almost possible using <bounds-remapping-list> in pointer assignment, but for the requirement that the <data-target> is simply contiguous, which doesn't include scalars.

 

So is the *real requirement* to be able to have an array pointer whose target is scalar? If not, then we already have all the tools required. (Noting in passing that we have effectively allowed this for default CHARACTER, as it is valid to pass a scalar to an assumed-size array in that case.)

 

Relaxing the rank-remapping-pointer-assignment rules to allow association of an array pointer with a scalar target (the array pointer must have size 1 for this to work) seems to be a more straightforward way of solving the problem.

 

HOWEVER, it seems that we can already do the C_F_POINTER hack, provided the user is willing to type another seven characters. That is, instead of

    CALL C_F_POINTER(X,...)

one can already type

     CALL C_F_POINTER(C_LOC(X),...)

 

I made a simple Fortran-only example that associates a rank-3 array pointer with a scalar using this hack, but I will refrain from cluttering up this message as I’m sure the original author doesn’t need such an obvious example.

 

Frankly, from a user viewpoint and a language design viewpoint I would prefer the aforementioned relaxation of the pointer association rules to this hack, but it’s true that we already *have* the hack available in the language, so there is not a strong case for the new feature.

 

(Feature two)

 

> Is there a special reason we prohibited non-interoperable scalars that do not have the VALUE from being dummy arguments in Bind(C) procedures?

 

Firstly, what has this to do with C_F_POINTER? Answer: Absolutely Nothing. It is a second suggestion for an unrelated new feature. This time it does seem to be related to C interoperability.

 

Secondly, yes of course there were reasons. C interoperability was debated at considerable length, and many boxes of ink were spilled writing many many papers (mostly physical papers not electronic). It was not without its controversial aspects.

 

At least one of the reasons  is that removing the few safeguards we have against mistakes would be seriously unsafe, and it would be invalid *according to the C standard as well as the Fortran standard* to call the routine from C. BIND(C) is meant for C interoperability, not for “please take off your seat belts and remove the brakes”.

 

I do not consider the requirement to write C_LOC(x) when passing non-interoperable objects via C to be a burden. It is arguably a good thing that the user has to signal specifically that he is doing that, rather than making the mistake of doing it inadvertently and getting no diagnostic.

 

As noted, TYPE(*) helps with some cases...

> Using TYPE(*) requires either a pointer or a SELECT TYPE construct

 

No, it does not require a pointer. And SELECT TYPE is not available, as that is not a context where TYPE ( * ) is permitted, for the very good reason that TYPE ( * ) frequently has no type info attached.

 

Given what I understand (or misunderstand) of Van’s use case, I don’t think that TYPE ( * ) is going to be useful here. But then, I think that the “old way” of explicitly passing things is fine.

 

> After all, Fortran 77 actually worked.

 

FORTRAN 77 did not have BIND(C), so no, it always failed for interoperable procedures since it had none.

 

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

 

No, it has the considerable value of diagnosing inadvertent attempts by the user to blow his foot away. It is entirely appropriate for the “risky” functionality to require some additional typing to confirm that the user does indeed want to access that particular functionality.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210504/4912ecc8/attachment-0001.htm>