(j3.2006) Question about 29113

[Malcolm Cohen]

I wrote:
> You cannot call malloc multiple times and say "oh I wanted the same
> memory back".

Van replies:
> That's not what C_F_POINTER does.

However it is what this part of the feature is intended to do.

...
>> You get one chance to assign the result of malloc to a pointer, then
>> you have to use that pointer.
...
> but I think this is OK:

Right, in the mixed-language case we have introduced a user-visible temp 
into the equation; this is not visible in either single-language case, but 
is unavoidable in the mixed-language case.  What we can say is that we don't 
support "shenanigans" based on the fact that this is visible.  Which indeed 
we effectively do, by requiring that the C to Fortran pointer be done 
precisely once, in AND ONLY IN the case where we are using the "storage 
sequence" interpretation.

There is no change to the pre-existing cases of the feature.  None.

>> It's the same idea here.  You get your C address back from the C
>> function and then you create ONE Fortran pointer for the object;
>
>How are these different?

This is using case (i) of the feature anyway.  So the whole premise is moot.

Hmm, looking at the text for case (ii), it would probably be better to say
   "CPTR is equal to the result of a reference to C_LOC"
rather than
   "CPTR is the result of a reference to C_LOC"
since even in
  CPTR = C_LOC(X)
CPTR is only equal to the result of the function reference, it is not the 
actual result as such.

(again)
>How are these different?
>
>module M                          module M
>  use ISO_C_Binding                 use ISO_C_Binding
>  type(c_loc), public :: C          real, pointer, public :: P

Pretty obviously different.

> If the
>second one is permitted, it is absurd that the first is not.

It is absurd to write screeds of text to describe how this purported 
extension would work in general.  When it fits into Case (i) or Case (ii), 
fine it is already covered.

I wrote:
> any further manipulations must be based on that Fortran pointer,
> otherwise the floodgates are open to all kinds of aliasing with broken
> types.

Van replies:
>What's broken about real?  What's new or broken about having two Fortran
>pointers that have the same target?

It is not allowed to have Fortran pointers of different type referring to 
the same target.

>  Those floodgates were opened in
>1990.  And a different floodgate involving EQUIVALENCE was opened in
>1966.

None of Fortran 90-2008 permit Fortran pointers of differing type to refer 
to the same storage, regardless of EQUIVALENCE (which is not allowed for 
TARGET).

>  This is not a new thing.

On the contrary, it would be entirely new and entirely unwanted.

As I wrote:
> Changing the design to do additional things is absolutely not in the
> remit of integration.  There is nothing broken here to fix.

-- 
........................Malcolm (typhoon has passed) Cohen.