forums.silverfrost.com

[Kenneth_Smith]

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.

[wahorger]

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.

[Kenneth_Smith]

Thanks Bill, you comments are useful.

I tracked down the relevant part of the standard:

[PaulLaidler]

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.

[Kenneth_Smith]

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".