Intel® Software Network

Chapter 14 of Metcalf, Reid and Cohen describes the following code sample ("Figure 14.5"):

module lib_code
    use iso_c_binding
    type :: pass
        integer :: n
        real, allocatable :: a(:)
           : ! more stuff
    end type pass
    type(pass), pointer :: struct
contains
    subroutine initialize(n, data) bind(c)
        integer(c_int), value :: n
        type(c_ptr), intent(out) :: data
        allocate(struct)
        struct%n = n
        allocate (struct%a(n))
        data=c_loc(structt)
    end subtouine initialize
    subroutine add(data, ...) bind(c)
        type(c_ptr), intent(in) :: data
          :
        call c_f_pointer(data, struct)
          :
    end subroutine add
end module lib_code

...and comments:

"When the C code calls initialize, it passes the size. The Fortran code allocates a structure and inside it stores the size and allocates an array component; it then returns a pointer to the structure. The C code later calls add and passes additional data together with the pointer that it received from initialize. The Fortran procedure add uses c_f_pointer to establish a Fortran pointer for the relevant structure. Note that C may call initialize several times if it wishes to work simultaneously with several problems; each will have a separate structure of type pass and be accessible through its own 'handle' of type (c_ptr)."

Well and good;  the explanation is clear enough, and this is exactly what I want to do. Looking at the code, though, makes me feel uneasy, as it's not obvious (a) how the compiler ensures that memory occupied by a previously-defined pointer is not overwritten, as no variables here have the 'save' attribute, or (b) assuming that they are somehow automatically saved, how then does one deallocate them later and so avoid a memory leak? Will a simple deallocate(struct) do the trick?

In C++ and other languages, this situation is a little clearer because one creates a named object, based on a class, one can store the object (or a pointer to it) in an array, and knows to call the object destructor when one is done. Here, things don't look so safe: I picture a number of disembodied structs floating around in memory with nothing to keep track of them except some handles that, one hopes, the C application is looking after properly.

Am I being too pessimistic here, or are there some other elements I need to add to the template to ensure that nothing gets overwritten or lost?

Thank you,
Stephen.