The Fortran standard states under “10.9.1 List-directed input”:
The form of the input value shall be acceptable for the type of the next effective item in the list.
When an I/O list used with list-directed input contains an integer and the input data contains a decimal point, programs compiled with PGI 14.7 produce no error. Thus, reading “14.7” into an integer variable causes the variable to have the value 14.
Here is a test program, for your convenience.
double precision Area,Hmin,Hmax,H0
character(len=26) :: inplin='TANK 1 820 10 15 14.99 0.1'
character(len=3) :: ilin = '3.1'
write(*,*)'K1 = ',K1
write(*,*)'K2 = ',K2
I will forward this question to our Fortran language experts, and see if they agree with your interpretation of the standard. For what it’s worth, I have observed that the Intel 2015 compiler behaves exactly the same way as the PGI 14.10 compiler on your test program:
cparrott@sb-parrott ~/UF/20141008 $ ifort -o test_intel test.f90
cparrott@sb-parrott ~/UF/20141008 $ ./test_intel
K1 = 0
K2 = 3
cparrott@sb-parrott ~/UF/20141008 $ pgfortran -o test_pgi test.f90
cparrott@sb-parrott ~/UF/20141008 $ ./test_pgi
K1 = 0
K2 = 3
However, GCC 4.9.0 does flag an error here:
cparrott@sb-parrott ~/UF/20141008 $ gfortran -o test_gcc test.f90
cparrott@sb-parrott ~/UF/20141008 $ ./test_gcc
At line 8 of file test.f90
Fortran runtime error: Bad integer for item 7 in list input
I checked with our lead Fortran developer, and he has said that this behavior is expected. It is an extension of the Fortran standard designed to allow certain very important legacy applications to run without failing.
If you like, I could file a Request For Enhancement to flag this case as an error if you compile it with the -Mstandard flag, but he has stated that this is unlikely to be given high priority at this time, with all the other features currently under development.
Hope this helps,