Danger of format * (list-directed I/O)

22 views
Skip to first unread message

John Harper

unread,
Nov 11, 2020, 6:27:41 PM11/11/20
to gg95
Apologies if I am telling you something you already know. I had thought for decades that list-directed I/O was quick and easy, and lost only a little accuracy, but I found recently that using it to write then read can change a huge double precision value very drastically. Two compilers printed the same number 1.7976931348623157E+308 three times with this program, but a third compiler gave a positive value of io , and the two print *,x statements gave 1.797693134862316E+308 and Infinity. Should the third compiler have left x undefined after the read statement? F2018 12.11.2 paragraph 2 seems to suggest that, because it includes

"If an error condition occurs during execution of an input/output statement that contains either an ERR= specifier or an IOSTAT= specifier then:...
        (6) if the statement is a READ statement or the error condition occurs in a wait operation for a transfer initiated by a READ statement, all input items or namelist group objects in the statement that initiated the transfer become undefined;"

If x had become undefined then the program would have violated f2018 12.6.4.5.1 paragraph 10, which says

"On output, every entity whose value is to be transferred shall be defined."

(However I was glad that the read statement did give x a value. That, and the first two print statements, helped identify the problem.) 

  program teststarfmt
    implicit none
    real(kind(1d0)):: x = huge(1d0)
    integer io
    character(80) line
    print *,x 
    print "(1X,ES24.16E3)",x
    write(line,*) x
    read(line,*,iostat=io) x
    if (io/=0) print "(A,I0)", 'io=',io
    print *,x
   end program teststarfmt

Reply all
Reply to author
Forward
0 new messages