Character value changing

[gib]

I have a module variable

character*(128) :: cellmlfile

which is read from a text file, within subroutine reader.  I set the first space (at position 49) to NUL, because this will be used later as an argument in a call to a C function.  Just before returning from the subroutine ichar(cellmlfile(49:49)) = 0.  In the calling subroutine, the value immediately on returning from subroutine reader is set back to 32 (the whole string is exactly what was originally read.)

What could cause this?  I am using IVF 11.0.075.

[gib]

I realise that a better method is to use iso_c_binding, and define

character(kind=c_char,len=128) :: cellmlfile_c

cellmlfile_c = cellmlfile

and use cellmlfile_c in the C call (and this is what I'm now doing), but I'd still like to know why NULL in the string gets changed back to space.

[mecej4]

This test program meets your description, but fails to show the behavior that you reported. I tried with Ifort 9.1 and 11.1.

module gmod
character(len=128) :: cellmlfile
end module

program gibx
use gmod
integer i
call reader()
write(*,*)' In Main'
write(*,'(1x,32Z3)')(ichar(cellmlfile(i:i)),i=1,128)
end program

subroutine reader()
use gmod
integer i
open(10,file='gib.dat',status='old')
read(10,'(A)')cellmlfile
close(10)
cellmlfile(49:49)=char(0)
write(*,*)' In Reader'
write(*,'(1x,32Z3)')(ichar(cellmlfile(i:i)),i=1,128)
return
end subroutine

Example data file contents:

123456789A123456789B123456789C123456789D12345678 E123456789F123456789G123456789H123456789I123456789J123456789K123456789L123456789M

Output:

  In Reader
  31 32 33 34 35 36 37 38 39 41 31 32 33 34 35 36 37 38 39 42 31 32 33 34 35 36 37 38 39 43 31 32
  33 34 35 36 37 38 39 44 31 32 33 34 35 36 37 38  0 45 31 32 33 34 35 36 37 38 39 46 31 32 33 34
  35 36 37 38 39 47 31 32 33 34 35 36 37 38 39 48 31 32 33 34 35 36 37 38 39 49 31 32 33 34 35 36
  37 38 39 4A 31 32 33 34 35 36 37 38 39 4B 31 32 33 34 35 36 37 38 39 4C 31 32 33 34 35 36 37 38
  In Main
  31 32 33 34 35 36 37 38 39 41 31 32 33 34 35 36 37 38 39 42 31 32 33 34 35 36 37 38 39 43 31 32
  33 34 35 36 37 38 39 44 31 32 33 34 35 36 37 38  0 45 31 32 33 34 35 36 37 38 39 46 31 32 33 34
  35 36 37 38 39 47 31 32 33 34 35 36 37 38 39 48 31 32 33 34 35 36 37 38 39 49 31 32 33 34 35 36
  37 38 39 4A 31 32 33 34 35 36 37 38 39 4B 31 32 33 34 35 36 37 38 39 4C 31 32 33 34 35 36 37 38

[gib]

That simple test program is fine here, too.  I'm sure this indicates something faulty in my code, but I can't imagine what sort of error could have this effect.  I really need to track it down.  I turned on run-time checking but nothing showed up.

[jimdempseyatthecove]

gib,

prior to call, use the memory watch window to specify the character variable, principally to obtain the hex address of the start of the character variable, then compute the memory address in hex of the location of the null. You can then use Break on memory change (C/C++ format using hex address 0x....). Then continue to perform the call. You should then get a break at the offending place in your code.

Note, the memory change break point accepts hex address as if done with C/C++ regardless to the fact that you are debugging a Fortran program.

Jim Dempsey

[gib]

Thanks for the suggestion, Jim.

I've now discovered what sort of mistake causes this problem - a stupid one.  First I noticed that it didn't matter what I appended to the string, it was always returned with spaces.  This was the clue.  Two factors combined to produce this effect.  First, cellmlfile gets initialised in a different part of the program before the call to reader, for reasons that are a bit complicated to explain (I display the contents of the file in the Qt GUI that is the main program, by means of a call to a Fortran DLL function).  Second (the really stupid part) at some time I had made cellmlfile a local variable in the reader subroutine.  Changes in reader had no effect on the global variable, which had already been given the value that was read from the file.

Sorry for the time-wasting!