More fun with pointers

I know this is the sort of thing that everyone has to wrestle with when they first start wrestling with pointers; I'd be immensely grateful if someone could point ouf why it doesn't work and how to *make *it work. Consider the following code, a mini-version of what I'm trying to do for real. I'm using user-defined types with pointer components, so the storage can be sized and allocated at run-time. I'm trying to:

• use a first variable of such a type as working space,
• assign the result to a second variable of the same type,
• free up the storage allocated to the first

But as soon as I free the storage for the first variable, all the data in the second variable turns to garbage. The code below illustrates. My question is, is there a way to make the data in the second variable 'non-volatile'?

    program more_fun_with_pointers
    type may_contain
      integer, pointer :: nuts (:) => null ()
    end type may_contain
    type (may_contain) brazil, cashew
    integer nut
    allocate (brazil% nuts (10), cashew% nuts (10))
    do nut = 1, 10
      cashew% nuts (nut) = nut
    end do
    brazil = cashew
    deallocate (cashew% nuts)
    stop    
    end program more_fun_with_pointers

I do not see a problem. What do you mean by the first variable?

In the code I posted, first variable = cashew, second variable = brazil. Try it in the debugger. Break on the deallocate statement and display the contents of cashew and brazil - they will be identical to each other, and as expected. Now step to execute the deallocate. cashew will become all null pointers, as expected - and when it does, brazil will become garbage, not as expected.

Now here's a thing. I'm posting this from home and I wanted to do this process again myself, so I could be accurate about what happens when the deallocate statement is executed - and when I tried to compile the code, my installation of FTN95 which was working just fine until a few days ago, now reports:

Salford run-time library. Insufficient memory available for CHECK mode Fatal run-time error*** Compilation abandoned

The only reference I can find to this message in the forum is from two years ago, in the context of problems with 64-bit versions of Windows. I'm still running XP Home SP3, so what can have gone wrong?

I've run the diagnostic tool. I don't have any extraneous copies of salflibc.dll lying around. (Not strictly true; the tool finds the expected two up-to-date 10.2.1.9 copies in the installation folder, and one 8.9.3.14 copy in a recycler folder. When I look in the recycle bin, it's not there - so that's a bit odd).

Any other ideas? I have had some Windows updates download and install themselves in the last couple of days - could something in one of them be responsible?

Andy

I have done exactly this and do not see a problem. I am running the latest release of FTN95. Don't know what is using up the memory.

Hmmm. I have v5.4 at work and v5.2 at home. I'm a 'late adopter' of v5.4 and I'm no longer able to upgrade myself at work, so had been hanging back on v5.5 installation hot on heels of v5.4. Better get both machines up to v5.5 and report back.

Quoted from sparge Better get both machines up to v5.5 and report back.

Well, getting work machine up to v5.50 was unusually quick and painless. However, I still get the same result. When I deallocate cashew, brazil evaporates. Specifically, after deallocation the two variables contain the following data:

cashew% nuts (1): NULL pointer cashew% nuts (2-10): Illegal pointer

cashew% nuts (1-2): 262520 cashew% nuts (3-10): -17891602

Can we compare ftn95/config options? I'm using /windows and /implicit_none.

I was using /checkmate. I can now see the problem by using /debug. I will investigate further.

The problem here is a subtle programming error.

The line

brazil = cashew

causes the pointer (address) for nuts to be copied and not the contents of the array. So the pointer brazil%nuts is over-written and lost.

This line should be

brazil%nuts = cashew%nuts

These are both arrays and the result is a block copy as intended.

I suppose one could argue that FTN95 is wrong in this context. I will have a look at the Fortran Standard to see if it has anything to say on this.

The Fortran standard does deal with this situation and FTN95 does it correctly. See section 7.5.1.5.

Roger. However, as you found yourself when using /CHECKMATE, the code behaves as one might naively expect rather than as it should. So there's still a fix to be made.

As it turns out there is no bug to fix even for /checkmate. /checkmate uses a different memory management model and so responds to the programming error in a different way.

In this case deallocate does something to the pointer but the change is not copied to brazil%nuts. At this point in the program the memory still exists and has not been used for other purposes. Hence brazil%nuts still looks OK.