CHARACTER assassination

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

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

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

Did you examine memory under debugger control? Look at the memory for variable triple 1 and compare with that for triple 2. Triple1 looks like this (in pseudo-memory notation):

abcdefhi jklmnopq rstuvwxy

as it should, whereas triple 1, which should look identical, looks like this:

a000b000 cd000e00 0fg000h0 00ij000k 000lm000

etc. Weirdly, it all seems to work (albeit I haven't tried very hard to trip the compiler up on its own bizarre memory-setting; I just wanted to illustrate that it is happening), but try getting it to talk to a different compiler that is expecting data that hasn't been expanded into 4/4/1-byte alignment ...

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.

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'.

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?

Quoted from jjgermis 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?

Thanks for reproducing my result! Are you using the most recent version of FTN95 (because I'm not).

Why would one want to catch the compiler in a web of its own making? Because that would provide good evidence for a compiler bug that actually needs to be fixed. I can think of no legitimate reason why a variable defined like this should be stored in memory in this way; given that it is, I deduce that something is broken behind the scenes. At the moment, the compiler behaviour is merely idiosyncratic (until one tries to do mixed-language stuff); there is no compelling reason to fix that which is not (visibly) broken.

Andy

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.

Quoted from sparge Are you using the most recent version of FTN95 (because I'm not).

The latest version we have is 5.21 I think. However, I tested the example program with 4.71.

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.

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.