(j3.2006) Question about 29113
Mon Oct 6 04:56:44 EDT 2014
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 126.96.36.199. 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 188.8.131.52. 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
> 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
> 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.
More information about the J3