Fortran ISO_C_BINDING C_F_POINTER C memory ownership at the C-Fortran boundary

Direct Answer

C retains ownership of the memory. The Fortran pointer associated via C_F_POINTER is valid only while the C allocation lives. The standard-conforming deallocation sequence is: C allocates → Fortran uses pointer via C_F_POINTER → Fortran signals completion → C frees. Reversing this order (C frees while Fortran still holds references) is undefined behavior. Fortran may call a BIND(C) free function, but only after the last Fortran reference; C must retain lifetime control in standard-conforming code.

Confirmed Facts from the Standard

• No ownership transfer: C_F_POINTER (Fortran 2018, 18.2.3) associates a Fortran pointer with a C address but does not transfer allocation status, finalization responsibility, or ownership.
• Pointer invalidation: The Fortran pointer becomes undefined immediately when the C object is deallocated. Any subsequent access is undefined behavior.
• Non-interoperable components: Derived types containing allocatable or pointer components are not interoperable with C (18.3.3). C cannot directly manage Fortran allocatable components.
• No Fortran deallocation: No Fortran DEALLOCATE or finalizer can release C-allocated memory; only the matching C deallocator (free, custom destroy) may do so.
• ASSOCIATED limitation: ASSOCIATED(ptr) returns true even after C free; it does not detect invalidation.

Likely Explanation and Practical Guidance

The standard deliberately leaves lifetime management to the programmer because C and Fortran have different memory models. The C allocator must outlive every Fortran reference in standard-conforming code. A typical safe pattern:

1. C allocates with malloc (or a matching allocator) and passes the address to Fortran.
2. Fortran calls C_F_POINTER(cptr, fptr) to associate a Fortran pointer.
3. Fortran reads/writes through fptr.
4. Fortran signals completion (callback, return from BIND(C) procedure, or explicit notification).
5. C calls free (or its destroy function) after step 4.

If Fortran must request deallocation, expose a BIND(C) procedure that Fortran calls to notify C; C then frees. Do not call free directly from Fortran on a pointer that Fortran still references.

Steps for This Case

1. Ensure the C type is interoperable: no allocatable/pointer components, use BIND(C) on the Fortran derived type.
2. Allocate in C with malloc/calloc/aligned_alloc (or a documented C API allocator).
3. Pass the raw address to Fortran; associate with C_F_POINTER.
4. Use the Fortran pointer only while the C allocation is guaranteed alive.
5. Arrange a clear handoff: Fortran finishes, then C frees. Document the boundary in both codebases.

One Missing Diagnostic Detail

What C allocator is used? If it is not malloc/free (e.g., a pool allocator, mmap, C++ new, or a custom arena), the matching deallocator must be called from C, and the same lifetime rule applies. This changes the recommendation only if the allocator/deallocator pair is mismatched.

Verification Checklist

• Compile with -std=f2018 -Wall -Wextra (gfortran, ifort, nvfortran, flang).
• Run under AddressSanitizer (-fsanitize=address) or Valgrind to catch use-after-free across the boundary.
• Write a minimal test: C malloc → C_F_POINTER → Fortran read/write → C free → Fortran read (should trigger ASan/Valgrind).
• Consult ISO/IEC 1539-1:2018 clauses 18.2.3 and 18.3.3 for the normative text.