C_f_pointer() borderline interpretation

Help
21

I have been thinking about the utility of an “extended assignment statement” without a RHS:

b=3.14
! calculate with b
b=    ! explicitly undefine b

Now, the compiler can easily discover that b is “dead” and print *,b is not legal, without having to prove theorems.

22

What about

subroutine undefine(a)
  integer, intent(out) :: a ! or whatever type, kind, rank you want
end subroutine

The intent(out) inherently “undefines” the variable on entry, and since it’s not defined in the procedure, it is thus undefined on return. If you make it intrinsic then the compiler can use that property in its analysis. Of course, what I generally do, and is somewhat safer is

block
  integer :: a
  ... ! make use of a
end block
! a no longer even exists

or even better

associate(a => (expr))
  ... ! make use of a, but can't modify it
end associate
2 Likes
23

The problem with this approach is that sometimes, that is exactly the situation that the programmer wants to be in, and adding all these restrictions to fortran to try to prevent type punning just makes the language harder to use. For example, suppose you have a buffer that is intended to be used in message passing or with i/o. The programmer wants to fill that buffer with mixed data of type integer, real, logical, and complex, of various kinds. The programmer can pack that data on the sending side, and he can unpack that data on the receiving side using, for example, equivalence, or pointer punning, or argument punning, or transfer().

There is no other practical way to achieve this result other than using those kinds of tricks.

So we could go in two directions with the language. 1) provide some standard conforming way to achieve that goal, or 2) make it illegal so that any programmer who wants to accomplish that kind of task is required to use another language. Some people insist on the first approach, some insist on the second.

Is there some third alternative that would keep both camps happy?

24

I think this is a good example to discuss.

One interpretation of the phrase “not in use by any other fortran entity” is that the ii(:) array was “using” that storage sequence up until the ii=>null() statement, after which time it is no longer using that storage, and p is the only fortran entity that is now associated with that storage sequence. Thus it now becomes standard conforming to use p as an argument to c_f_pointer().

But another interpretation of that phrase is simply that the programmer does not use the array ii(:) after the c_f_pointer() call. That is, if the program does not reference ii(:) afterwards, then it is not “in use”.

That second interpretation allows, for example, nonpointer arrays (or intent(in) pointer arrays) to be pointer punned through c_f_pointer(), while the former does not, and is thus much more general (and more useful).