forums.silverfrost.com

[sparge]

The following trivial code fragment, using the two (non-standard) Salford functions loc and ccore1, has me rather worried. It arose out of my continuing work on issues referred to in these two recent threads:

http://forums.silverfrost.com/forums/forum.asp?forumid=3&msg=1791
http://forums.silverfrost.com/forums/forum.asp?forumid=3&msg=1852

loc is not documented - just mentioned here and there in the documentation - and purports to return the address of the argument supplied.

It appears that, unless code is compiled with /checkmate, loc returns an incorrect (and illegal) address when supplied with a specified single character from either a character string or an array of single characters.

On my machine, the incorrect addresses are of the form 0x202020.. which seems like a good clue as to what is going wrong (albeit not to me).

The workaround is obvious - once the need becomes apparent. But I can't see any reason why there should be a need. Worse, I can't see any reason why the incorrect address returned by loc will necessarily always be illegal.

program core_blimey
integer, parameter :: dim = 1
character cha
character (len = dim) cha1da
character cha1db (dim)
integer pcha, pcha1da, pcha1db, pcha1da1, pcha1db1
intrinsic loc, ccore1
! request the address of a single character
pcha = loc (cha)
! request the addresses of a string and an array of single characters
pcha1da = loc (cha1da)
pcha1db = loc (cha1db)
! request the addresses of a single character from the string and the array
pcha1da1 = loc (cha1da (1: 1))
pcha1db1 = loc (cha1db (1))
! the first three addresses are correct.
ccore1 (pcha) = '!'
ccore1 (pcha1da) = '!'
ccore1 (pcha1db) = '!'
! these two are only correct with /checkmate;
! otherwise, they are so wrong as to cause access violation
! incorrect addresses are of form 0x202020??
ccore1 (pcha1da1) = '!'
ccore1 (pcha1db1) = '!'
stop
end program core_blimey

[PaulLaidler]

Andy

It looks like you have found a compiler bug and I will put it on the list of things to do.

My guess is that implementation of LOC in FTN95 is incomplete and that chaqdb(1) is being wrongly interpreted as a function call with 0x2020... being the undefined pointer to a function.

It is less obvious that one would want to have loc(cha1da(1:1)) but if it works with CHECKMATE then I guess we should make it work for non-CHECKMATE.

As to why 0x2020... is illegal, the basic reason will be that it is not in the address space of the application. Someone with more experience of these matters will know better but it could, for example, belong to the operating system address space.

[PaulLaidler]

Andy

This bug has now been fixed for the next release.