forums.silverfrost.com

sparge · Joined: 11 Apr 2005 Posts: 371

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 ( Smile

=> 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

PaulLaidler · Posted: Thu Mar 11, 2010 7:21 pm Post subject:

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

sparge · Joined: 11 Apr 2005 Posts: 371

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

PaulLaidler · Posted: Fri Mar 12, 2010 10:05 am Post subject:

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.

sparge · Joined: 11 Apr 2005 Posts: 371

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.

sparge · Joined: 11 Apr 2005 Posts: 371

PaulLaidler · Posted: Fri Mar 12, 2010 6:27 pm Post subject:

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

PaulLaidler · Posted: Sat Mar 13, 2010 9:02 am Post subject:

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.

PaulLaidler · Posted: Sat Mar 13, 2010 9:19 am Post subject:

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

sparge · Joined: 11 Apr 2005 Posts: 371

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.

PaulLaidler · Posted: Sat Mar 13, 2010 5:23 pm Post subject:

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.