forums.silverfrost.com

[sparge]

Consider the proglet below. Even better, build it and run it under debugger control. Then step through, examining memory as you do so. I thought it was a 4-byte alignment issue at first until I experimented with type triple2.

If it was all within the confines of FORTRAN, it wouldn't matter and I'd probably never even have noticed. But I'm calling a routine written in C, which uses its own version of type triple1. No problem, I thought, I'm using FORTRAN 95 now, I can talk to it in its own language. But evidently not. And obviously I can work around the issue using type triple2, now I know there is an issue to work around. But I am curious to know what on Earth is going on, and why?

Andy

program test_triple_type

type triple1
character x
character y
character z
end type triple1

type triple2
character(len = 3) xyz
end type triple2

type (triple1) triplets1 (2), egtrip1
type (triple2) triplets2 (2), egtrip2

triplets1 (1) = triple1 ('a','b','c')
triplets1 (2) = triple1 ('d','e','f')
triplets2 (1) = triple2 ('abc')
triplets2 (2) = triple2 ('def')

egtrip1 = triplets1 (1)
egtrip2 = triplets2 (1)

stop
end program test_triple_type

[jjgermis]

I tried the program and, unless I miss the issue, it works fine. What should happen? Is some of the variables assigned wrongly?

[sparge]

[jjgermis]

To be honest, I do not know how to examine memory in debugging. I tried several options from the debugger menu and could not find the results that you reported. Should I use Debug Win32 or Checkmate Win32 and do you use Plato or Visual Studio.

[sparge]

You should use Debug Win32 (Checkmate Win32 and single character variables do not play nicely together, 1/256 of the time on average ). I use Plato.

Start by Build-Step Into from the Plato menu. In the Variables window (Window-Variables from the debugger menu if it's not already open), right click any variable and choose Memory Dump at Variable to open a window showing you that variable as it is stored in memory.

Set a breakpoint (F2) at the STOP statement and run the program to that point. Open memory windows for variables triplets1 and triplets2.

On my machine, the single characters of actual data in triplets1 are interspersed with null bytes in a very odd way. In triplets2, the data looks as I would expect.

egtrip1 and egtrip2 are there as a preliminary attempt to see if I could catch the compiler in a web of its own making - so far without "success".

[jjgermis]

As mentioned, I never used the memory dump before. However, I followed your instructions (thanks for the step-by-step explanation) and got the same result as you mentioned in your previous post.

I cannot say much to the result, other than that I get the same as you. Why should one want to catch the compiler in a web of its own making?

[sparge]

[PaulLaidler]

I have had a brief look at this can can confirm that a) the result is correct and b) the values are stored correctly in memory and c) the alignment in memory is unexpected.

There may well be a reason why it has been coded in this way but the reason is not immediately apparent to me.

Clearly it would not be wise to assume a particular memory alignment in this context when communicating with other languages.

[jjgermis]

[sparge]

Thanks for getting back to me on this, Paul. I'm reassured that you are able to reproduce the result and agree that the memory alignment seems odd. It does all seem to work, though ... so unless it contravenes some part of the standard, or indirectly indicates something that actually needs to be fixed (and only you can be the judge of that), I suppose there's nothing more to do except for mixed language users to be aware.

[PaulLaidler]

I am running the latest version but I don't think it will make any difference.
There is no reason to suspect an associated bug in the compiler.