(j3.2006) Question about 29113

[Van Snyder]

Malcolm Cohen wrote:
> 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.
>   

That is not entirely (or even partly) obvious by reading the description 
of C_F_POINTER, or indeed anything else in 007 or 29113 or the papers 
that led to 29113.  Where does it say that C_F_POINTER references 
malloc, or any other storage allocator?  Did I miss it?  Unless it's 
misspelled somewhere important in 007, so a search in Acrobat Reader 
fails to find it, the only places "malloc" appears are in C.10.1p2 and 
an example in C.10.12.  MPI_ALLOC_MEM does not appear at all.

> ...
>   
>>> 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's a long list of storage sequence definitions in 16.5.3.2. If 
those definitions are not what's meant in the fourth paragraph of the 
description of FPTR, some words to deny it would be helpful.  If that 
definition is the one that applies, then the fourth paragraph repeats 
the possibilities of the second and third ones.  It would be helpful if 
the last three paragraphs of the description of FPTR were disjoint, if 
that's what we want, instead of overlapping.  The description of FPTR 
you're expecting me to believe, without any supporting words in the 
standard, means that the fourth paragraph of FPTR contradicts the 
definition of CPTR, and is therefore impossible to obtain.  That is, the 
second paragraph of the description of FPTR covers the case of the first 
item in the list of the description of CPTR, and the third paragraph 
covers the second item.  There are no further items to which the fourth 
paragraph might refer.  Therefore, it either amplifies what's in the 
second and third paragraphs, or the conditions to apply it cannot 
obtain.  Even if a "something else" item were added to the list in the 
description of CPTR, it would still not be obvious that the fourth 
paragraph refers to a storage sequence that is neither interoperable nor 
not interoperable, which seems to cover the universe of discourse, or 
that the term "storage sequence" is different from the meaning given to 
it in 16.5.3.2.  It would be helpful to describe CPTR in such a way that 
the fourth paragraph were possible to obtain, and it would then be 
further helpful if the fourth paragraph were clearly disjoint from the 
second and third ones, not an amplification of their provisions.

>> 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.
>   

It's the result, not the text, that seems to be identical.  Can we take 
this seriously instead of splitting hairs?

>> 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.
>   

Given the description of CPTR, Case(i) and Case(ii) are the only cases 
that exist.

> I wrote:
>   
>> any further manipulations must be based on that Fortran pointer,
>>     

There's still the problem that in a program of substantial size, 
developed by several teams who share interface documents, but not 
subprogram source, whether the restriction is violated is unknowable to 
the developers.  This is a bad thing.  Yes, we've had the problem 
forever with COMMON, but that's been known to be a problem, which is why 
it's printed in small type.  We should not introduce further problems of 
this kind.  If we must introduce one, we should print the fourth 
paragraph of the description of FPTR in small type.

>> 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.
>   

Who advocated that?  I didn't.

The fourth paragraph of the description of FPTR doesn't say anything 
about the relationship of its type to the type of the storage sequence.  
Ought it?  If it did, there wouldn't be any question about having 
Fortran pointers of different type with the same target, and copying the 
C address to a Fortran pointer more than once would be harmless.  Since 
it doesn't, and it cannot be reached except in the allowed cases of 
values of CPTR, which reach the definitions of the second and third 
paragraphs, it is reasonable to assume that the restrictions on type in 
those two earlier paragraphs apply, with the result that Fortran 
pointers of different type referring to the same target cannot occur.

If it ought not to, what is the point of getting a Fortran pointer that 
has as its target the entity at the address specified by CPTR?  
Presumably, the reason is to "do something" in Fortran with the target 
of FPTR.  What can be done if its type is unknown, or unknowable, or 
arbitrary, or nonexistent in the Fortran universe?  If the reason is not 
to "do something" in Fortran, why not prohibit getting a Fortran 
pointer, and just drag around the C address instead?

> 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.
>>     

There is no design evident in the standard; there is only a restriction 
that appears to be completely arbitrary and unnecessary, in a paragraph 
that either amplifies the other paragraphs of the description, or the 
condition to apply it cannot be obtained.  Accusing me of wanting to 
change a design that remains a mystery, as far as the standard is 
concerned, doesn't make sense.  As far as the standard is concerned, 
leaving aside the possible existence of a secret design, all I want to 
do is to remove what appears to be a completely arbitrary and 
unnecessary restriction.  If and when the standard makes a case that the 
restriction is not arbitrary and unnecessary, it might make sense to 
keep it.  Failing that, either the feature or the apparently pointless 
restriction on it should be deleted.