Bug: Decimal point in input data for integer variable in I/O list does not cause error

[mecej4]

F2008, Section 10.9.1 says: 

9 10.9.1 List-directed input
10 Input forms acceptable to edit descriptors for a given type are acceptable for list-directed formatting,
11 except as noted below. The form of the input value shall be acceptable for the type of the next effective
12 item in the list.

The following program, therefore, should abort with an formatted I/O error (illegal character in numeric input).

program testinp
implicit none
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'
integer PipeID,K1,K2
character*4 AF
Read(inplin,*)AF,PipeID, area,Hmin,Hmax,H0,K1
write(*,*)'K1 = ',K1
read(ilin,*)K2
write(*,*)'K2 = ',K2
end

Other compilers (GFortran, NAG, Absoft, Lahey) cause this program to abort with errors. Intel Fortran (and PGI) blithely ignore the decimal point in the input and give the output

 K1 =            0
 K2 =            3

[Steven_L_Intel1]

I don't agree with your interpretation of the standard.  This is a requirement upon the programmer/user, not the compiler. As an extension, we allow any numeric type to appear in list-directed input for a numeric type, and do the conversion as would be done in intrinsic assignment. We don't have a way of making this into an error. The other compilers are within their rights to not have such an extension and give an error. Neither is wrong.

It is a pretty steady mantra that one should never rely on error reporting in list-directed input to perform input validation. The compiler is allowed to be, and often is, more permissive than you would like.