Bug with LEN in 8.50

If you try the following code in 64bit

!ftn95$free
subroutine test_len(i, j)
integer k
k = i+j
end

program test
  CHARACTER*18	:: PRF(3)=['Direct proof      ', 'Intermediate proof', 		&
  					       							'Indirect proof    ']
  i = 1
  j = 2
  call  test_len(i,j)

  call  test_len(i,len(prf))                         
end     

You get the following warning

WARNING - 189: In a previous call to TEST_LEN, the second argument was of type INTEGER(KIND=3), it is now     INTEGER(KIND=4)

Surely LEN is always KIND=3 ?

Yes you are right at least when you use /ISO on the command line. I will make a note that this needs fixing.

You can avoid the warning by changing to len(prf,3).

As in the case of SIZE, FTN95 does not conform to the Standard in this respect but ought to when /ISO is used on the command line.

I will take a chance and assume that you are not 'pulling my leg'...

No FTN95 is not clever enough to modify the code to conform nor would that be helpful to the user who wants to know if their code is portable.

Paul, John-Silver,

I also was confused about the word 'Ensures' in the documentation John quoted. For me 'ensures' is something active like 'guarantees' which I think is not meant, is it? I would prefer substituting 'ensures' by 'expects' in the quote. However, I am no native speaker 😃

The online help of ftn95 (ftn95 /?) says:

/ISO     Use strict ISO Fortran 95 rules, no extensions allowed

which I find more intuitive.

Regards, Dietmar

Hello,

one more remark concerning the debugger in this context: I am not able to set a breakpoint to the end statement of subroutine test_len using sdbg64, hence I cannot see the outcome of the assignment in the last call of test_len in sdbg64. Moreover, if sdbg64's mouse cursor hovers above a variable, say j, then the value of j is displayed. If moving the mouse cursor to variable i and then moving it back to variable j again, then the value of j is **not **displayed again for sdbg64.

Both is different to the 32 bit version of the debugger (sdbg).

Regards, Dietmar

Sorry, I just made a mistake in my last post where I complained about the sdbg64 variable j which I said was not dispayed a second time 😦

The correct scenario for sdbg64 is the following:

1. make the cursor hover above variable j hence the value of j is shown
2. move the cursor away from variable j until the value of j disapperars, but do not make the cursor hover above another variable
3. move the cursor back to variable j again;

Now from the 32 bit version of the debugger I would expect the value of j be displayed again. However, this is **not **the case for sdbg64.

I like this feature very much 😃

Sorry and regards, Dietmar

The original problem (when LEN is called in 64 bit code as the value of an argument) has now been fixed for the next release of FTN95.

Paul,

It's a word choice. I see on the front page that FTN95 is:

Welcome to the home of Silverfrost FTN95: Fortran for Windows (formally Salford FTN95). We let you use Fortran your way:

and I keep wondering if 'formerly' is meant.

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean – neither more nor less.'

'The question is,' said Alice, 'whether you can make words mean so many different things.'

'The question is,' said Humpty Dumpty, 'which is to be master – that's all.' (Looking-Glass 6.63-65)

Eddie (in leg-pull mode)

Ah yes. Thanks for letting us know.