Recursive I/O on internal files in Fortran 95?

From: Harald Anlauf (anlauf_at_hep.tu-darmstadt.de)
Date: 12/20/04

  • Next message: Lee Bassom: "Get name of mapped parameter....." 
    Date: 20 Dec 2004 12:03:54 +0100

    Hi,

    what is the status of recursive I/O on internal files in Fortran 95?
    I have a book on my desk that is rather unclear on that point and can
    be read as allowing it in that particular case.

    I checked the F2k3 draft, where in section 9.11 it appears that it is
    allowed (now?), although I have a hard time understanding the following
    excerpt:

      "A recursive input/output statement shall not modify the value of any
       internal unit except that a recursive WRITE statement may modify the
       internal unit identified by that recursive WRITE statement."

    I'm not a native speaker, so can somebody please explain it in some
    detail?

    In particular, I'd like to know whether the following code is legal:

    program test_rec_io
      implicit none
      character (len=4) :: s
      write (s, '(a)') foo (1234)
      write (*,*) s

    contains

      pure recursive function foo (i) result (s)
        integer, intent(in) :: i
        character (len=4) :: s
        ! Internal I/O, allowed recursive in f2k3
        write (s, '(i4.4)') i
      end function foo

    end program test_rec_io

    None of the compilers I tried complained during compilation with options
    set to strictest conformance. But only the runtime of Intel's ifort 8.1
    actually printed the (my) expected result. All others failed, i.e., the
    runtime trapped the recursion or gave funny results. 

    -- 
Cheers,
-ha
  • Next message: Lee Bassom: "Get name of mapped parameter....."

    Relevant Pages

    • Re: Which PIC18 C Compiler?
      ... The root reason is re-entrant code makes RAM space indeterminate. ... Some compilers may need help from a keyword to identify re-entrant code - others can figure it out automatically. ... What I think Rich found strange was Chris' claim that "professional" compilers would not support recursive code at all. ... As you say, recursion is not much used in 8-bit systems - and if it is, it's probably a bad idea. ...
      (comp.arch.embedded)
    • Re: "Too many continuation lines" error message (no solution, just comment)
      ... Note that Fortran also has recursion these days. ... I know of no current Fortran compilers that implement saved variables ... or common as anything other than static (well, ... In the realm of non-current compilers, memory was precious enough ...
      (comp.lang.fortran)
    • Re: "Too many continuation lines" error message (no solution, just comment)
      ... >>In C, which allows recursion, automatic variables must be ... Some of those might be written using the back end of C compilers. ... the source code documentation was mostly keyed to ... (in the days of impact printers where that worked). ...
      (comp.lang.fortran)
    • Re: Certified C compilers for safety-critical embedded systems
      ... In short words, real compilers are under high stress, imposed on them by rich ... First, such a compiler gets at least two input streams, and only one of them ... Second, a real compiler produces at least 3 output streams, and again, only ... Recursion means stack, and stack is very human thing, it rarely happens in ...
      (comp.lang.ada)
    • Re: inline recursive functions
      ... The inline keyword only is a recommendation for the compiler but does not change the semantics. ... I've seen C compilers that do, in fact, optimize certain tail-recursive functions to iterative ones and can subsequently inline the result. ... This optimization tactic isn't widely seen in compilers because it's too clever to pay off in practice; actual C code doesn't use tail-recursive functions often, if the inlining is critical a programmer would never rely on a compiler's ability to unfold tail recursion, and if the inlining is not critical, who cares? ...
      (comp.lang.c)