(j3.2006) Question about 29113
Mon Oct 6 06:15:20 EDT 2014
>Given the description of CPTR, Case(i) and Case(ii) are the only cases
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
>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
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 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.
More information about the J3