Bug in list-directed read: invalid integer not diagnosed

[Harald]

A friend showed me an interesting issue with list-directed read that occurs under very special conditions. It looks like an invalid integer is not diagnosed in list-directed read when

    a string occurs that starts with "i" (or "I", but not another letter)
    there is another element following in the same list-directed read

This is demonstrated by the attached code.

Is there an explanation for this somewhat unusual behavior?

Harald

[Harald]

Further explanation (I had to split and trim the submission, otherwise it got flagged as spam!?)

Running the program yields:

% ifort ifort-read-bug.f90 -g -traceback && ./a.out
 read 2 1 :            2 1      
 read i 1 :            0 1      
forrtl: severe (59): list-directed I/O syntax error, unit -5, file Internal List-Directed Read
[...]          
a.out              0804A48A  MAIN__                     15  ifort-read-bug.f90

[...]

[Steven_L_Intel1]

Not a bug, a feature. Values starting with i or I are considered to be Infinity or Inf, which is valid as a floating point input value. Similarly, n or N would be NaN. While the standard says that a standard-conforming program will have an integer value corresponding to an integer variable, we allow any numeric type and do the conversion. (We used to do this for LOGICAL as well but disabled that, except it can be re-enabled under an option.)

The observation I always make in such circumstances is that you should not rely on error detection in list-directed input, as the implementation is bound to allow things you don't want. (Consider that in list-directed, a comma or a slash is perfectly acceptable for any data type.)

If you want input validation you have to do it yourself. You can perhaps get away with using an explicit format with an I edit descriptor here - it will be less forgiving than list-directed.

[Harald]

Well, the intention may be good, but the runtime behavior is far from intuitive.  I replaced the integer i in the program by a real.  Reading "i" leads to a 0 (same as for an integer, where Infinity is not defined, nor Nan).  Only "inf" leads to Inf.  Same for "n"/"nan".  Furthermore, how come that reading a second item in the same list-directed read changes the way the first item is interpreted?  (Error/no error).

I am aware that some characters ("*", ",", "/") have a special meaning, but that's a completely different issue.

So well, I take your suggestion to do input validation myself.  It would just be too easy to rely on the Fortran runtime... ;-)

[Steven_L_Intel1]

That is interesting - I expected a somewhat different behavior. We'll look into it. Nevertheless, you do need to do your own validation.

[Steven_L_Intel1]

Ok, here's what's happening.

First, the run-time library sees the leading "i" and thinks that it might be Inf or Infinity. It then tries to convert this to a floating point value, but the conversion fails. Rather than give an error at this point, it simply saves the error status, sets the value to 0, and keeps processing list items. If the next list item is successfully read, as it is in the second case, then that overwrites the saved status with the result that no error is reported. In the third case, there is no subsequent list item so the error is reported.

As I mentioned above, it's an extension that a value allowed for a REAL is permitted to be used for an integer. But in this case the error should have been reported immediately rather than looking to see if there were more list items to process.  I have filed a bug report on this, issue ID is DPD200252810.

[Steven_L_Intel1]

Fixed in 15.0.