Recursive IO

In a previous discussion, Paul advised that in general recursive IO is not permitted in FTN95, with the caveat that it is permitted in certain cases.

Now consider the following program, which executes as intended by the programmer with other compilers.

Perhaps a bug, or perhaps not? It's the discrepancy between FTN95 and gFortran (for example) that I need to explain correctly to another party.

program test
  implicit none
  logical, external :: is_number
  print *, is_number('123.45')      ! .true.
  print *, is_number('  -12e-3  ')  ! .true.
  print *, is_number('  -12d-3  ')  ! .true.
  print *, is_number('abc123')      ! .false.
  print *, is_number('1.2.3')       ! .false.
end program test


logical function is_number(str)
  implicit none
  character(*), intent(in) :: str
  real :: tmp
  integer :: ios
  character(len=256) :: buffer
  ! Copy string into fixed-length buffer and trim it
  ! Try to read as a real number
  ! If successful (ios == 0), then it's a number so return true, otherwise false.
  buffer = adjustl(str)
  buffer = trim(buffer)
  read(buffer, *, iostat=ios) tmp
  is_number = (ios == 0)
end function is_number

It's not a function of the compiler; rather a limitation in the run-time. It's just a guess; it's likely that the library functions for I/O were written a very long time ago, and are not written to be recursive nor re-entrant. So they check to see if you try, and complain.

There is a way to write a 'C' function to do this. I had to resort to something like that (and using the library functions like PRINT_HEX1@) to output formatted data from within a device driver that looks like a FORTRAN I/O unit. That said, I can find no Silverfrost library functions that will do what you wish to do while not leaving the FORTRAN environment.

Thanks Bill, you comments are useful.

I tracked down the relevant part of the standard:

'An input/output statement shall not be executed if it is in a procedure that is referenced directly or indirectly in an expression in an active input/output statement.'

Yes the restrictions are in the runtime I/O library. They could be relaxed particularly in cases like this but I suspect that it would require a lot of work.

In this particular case the code could be changed so is_number becomes print_is_number which would be a subroutine that does the testing and then the printing in sequence.

Paul,

No need for any changes. I understand what is happening now, and can explain the discrepancy between for example gFortran and FTN95 in this case, in somewhat more technical terms than simply 'It disnae work'.