(j3.2006) Question about 29113

[Malcolm Cohen]

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

That certainly seems like a defect.  Putting the bits of Case (iii) that are 
talking about CPTR into the CPTR paragraph would be a substantial 
improvement!

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

And is completely unavoidable when messing with C.  That world is FULL of 
undetectable-without-the-source violation possibilities.  OTOH, maybe this 
one is not undetectable...

> We should not introduce further problems of this kind.

Absolutely, which is why we must NOT expand the size of this feature any 
further!

This is not restricting a previous feature, and your examples of how things 
might go wrong were not subject to these restrictions.  The restriction here 
is to keep the new feature portable without impacting its workability.

>> It is not allowed to have Fortran pointers of different type referring to
>> the same target.
>>
>
>Who advocated that?  I didn't.

You did not intend to advocate it, but that would be the result of removing 
the restriction.

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

Are you serious?  As stated several times (and in the original paper), this 
is not a renaming of Case (i) or Case (ii), it is a new case.  The memory in 
question does not have a "type" to conform to.  C memory allocators return 
"void *", pointer to anything.  It does not have a type of its own until we 
give it one.

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

The purpose stated in the paper that introduced the facility, to 
interoperate with a C memory allocator, in particular MPI_ALLOC_MEM.

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

The type of FPTR is known.

>There is no design evident in the standard; there is only a restriction

It is not a restriction.  It is an extra facility.

>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.
>
>If and when the standard makes a case

Standards don't "make a case".

You voted for this feature too.

> that the
>restriction is not arbitrary and unnecessary

Clearly it is not "arbitrary".  It is certainly not mathematically 
necessary, merely pragmatic.  The restriction could be reduced, at the cost 
of additional text and complexity to describe the reduction.  It cannot 
simply be deleted since that would "open the floodgates" as previously 
mentioned (leading to lots of contradictions and complaints).

>, it might make sense to
>keep it.  Failing that, either the feature or the apparently pointless
>restriction on it should be deleted.

Deleting the feature would not only also require a WG5 vote, but snubbing 
the MPI committee.

Improving the wording but retaining the intended technical content will not 
require going back to WG5.  Let's agree to improve the wording (which I 
never claimed should not be improved, indeed I've already agreed on several 
clarifications and wordsmithings) without technical change, and if you are 
unsatisfied then next WG5 meeting you can bring forward a request to delete 
or extend it at your pleasure.

Cheers,
-- 
............................Malcolm Cohen.