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