(j3.2006) Question about co-arrays

[Aleksandar Donev]

Hi all,

Firstly, as I said before, I am all for saying that C_PTR et al. act as if 
they are derived types with pointer components, and then deleting their 
special casing in favor of using the constraints already there for pointer 
components. But, I did not hear anyone actually agreeing with me, so I am 
assuming this is not attractive. In that case:

> If there is no technical justification, C526 should be struck entirely.
If C526 et al. are not there, then we need additional words in the standard to 
explain how co-arrays of type C_PTR are different than co-arrays of integers. 
And they are different:

type(c_ptr) :: x[10], y
real, pointer :: p

y=x[1]
call c_f_pointer(y,p)
write(*,*) p

The statement that is causing problems here is the copy of x[1] to y? Or maybe 
it is trying to convert an invalid C pointer (y) to a Fortran pointer? Or is 
it the attempt to de-reference p?

I claim: this has to *explicitly* be said in the standard.

>?It serves no useful purpose: 
In the opinion of at least 3 people it does serve a useful purpose, namely, it 
avoids giving the user more tools to do something stupid, like the example 
above. Whether this is a good policy or not is a decision not to be made by 3 
or one (Malcolm), but majority. I see both answers supportable by quoting 
examples from the existing standard (which has both plenty of tools to shoot 
ones foot but also has plenty of (often) restrictive and not really necessary 
constraints).

>?one can roll these things up and hide them, so it is 
> ineffective anyway.
This is the the only good reason I see to delete C526. Originally we tried to 
make C526 and related constraints effective, but we eventually realized there 
are holes. But the holes are not small---users that are smart enough to find 
them will know what they are doing. The hole of letting people declare 
co-arrays of type C_PTR freely is a larger one. What's wrong with patching 
the large hole but leaving the small one open?

Best,
Aleks