# C\_f\_pointer() borderline interpretation

**URL:** <https://fortran-lang.discourse.group/t/c-f-pointer-borderline-interpretation/7929>\
**Category:** Help\
**Created:** [April 30, 2024, 9:13am UTC](https://fortran-lang.discourse.group/t/c-f-pointer-borderline-interpretation/7929 "2024-04-30T09:13:41Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\
**Post date:** [May 2, 2024, 2:34pm UTC](https://fortran-lang.discourse.group/t/c-f-pointer-borderline-interpretation/7929/21 "2024-05-02T14:34:14Z")

</div>

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

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

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [May 2, 2024, 3:38pm UTC](https://fortran-lang.discourse.group/t/c-f-pointer-borderline-interpretation/7929/22 "2024-05-02T15:38:54Z")

</div>

What about

```fortran
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

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

```

or even better

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

```

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [May 2, 2024, 4:06pm UTC](https://fortran-lang.discourse.group/t/c-f-pointer-borderline-interpretation/7929/23 "2024-05-02T16:06:38Z")

</div>

> [@everythingfunctional](#):
>
> The current restrictions on `c_f_pointer`/`c_loc` are to prevent you from putting yourself back in that situation.

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?

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [May 2, 2024, 4:26pm UTC](https://fortran-lang.discourse.group/t/c-f-pointer-borderline-interpretation/7929/24 "2024-05-02T16:26:39Z")

</div>

> [@PierU](#):
>
> This is conforming:  
> […]

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

[Previous page](https://fortran-lang.discourse.group/t/c-f-pointer-borderline-interpretation/7929.md?page=1)