forums.silverfrost.com

[ljfarrugia]

Hello
The following subroutine fails on compilation with an error stating that key(*) is not allowed in this context. There was no problem with previous versions. It states the error is in this subroutine, but in fact it gives a line number indicating the position in the code where the failure occurs which is in the previous routine in the code, i.e. the line number is incorrect.

subroutine parseKeys(buffer,key)
implicit none
character*(*) buffer
integer i,j,k,success,key(*)

key = 0
k = 0
do i=1,LEN_TRIM(buffer)
if(buffer(i:i) == ' ') cycle
k = k + 1
read(buffer(i:i),'(i1)',iostat=success) j
if(success /= 0) return
key(k) = j
enddo
end

[Kenneth_Smith]

FTN9.20 is correct as whole-array operations are not allowed on an assumed size array here key(*), so change this to an assumed shape array key( : ), remembering that assumed-shape arrays require an explicit interface to the caller.

[ljfarrugia]

In a follow up to the previous comment, using version FTN95 9.0 the point of the error is actually given at the line

2914) key = 0
*** An assumed size array (bound of *) is not permitted in this context
1 ERROR [<PARSEKEYS> FTN95 v9.00.0]

which perhaps is making more sense, but I'm not sure why there is now an error, whereas in earlier version there was no compilation error.

In addition, I find that both FTN95 versions 9.0 & 9.2 give some strange warning messages, for example

4454) recursive subroutine rdInclude1(io,iout,filen)
WARNING - In a call to RDINCLUDE1 from another procedure, the first argument was of type INTEGER(KIND=3), it is now INTEGER(KIND=3)
WARNING - In a call to RDINCLUDE1 from another procedure, the second argument was of type INTEGER(KIND=3), it is now INTEGER(KIND=3)

Its complaining that the argument is the same in both calls?????
An additional problem with version 9.20 over 9.0 is that the line numbers are incorrect in 9.20, but correct in 9.0

Louis

[ljfarrugia]

Thanks Kenneth
I changed key(*) to key(MAXSCALE+ which was the declared size in the previous routine, which luckily was the only routine calling the problem subroutine, so the change was trivial and easy.

The problem of version 9.20 reporting wrong line numbers for errors and warnings remains and this makes it difficult tracking down such issues.

Louis

[ljfarrugia]

Sorry don't know why emoji appears, I meant MAXSCALE+8

[mecej4]

Try setting "smilies" to OFF in your forum profile.