Integer edit descriptor with float list item

[Sebastien_B_]

Dear Intel support team, when I try to read an integer value with the I integer descriptor into a real variable, ifort returns an incorrect value and no error status. You will find below my ifort version and the demonstration program. Quoting the Fortran standard 2008 (section 10.7.2.2): "Integer editing: Iw [...] The specified input/output list item shall be of type integer". Obviously, I violate this rule, so I would expect an error status. Or if you want to extend the standard, you could implicitly convert the integer value to the real variable. Anyway, my worry is that an incorrect value is returned with no detection possible. May be I should add that in my real use case, the string to be read and the format used are NOT known at compilation time. Only the list items (type real) are known. Sebastien $ ifort --version ifort (IFORT) 14.0.2 20140120 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. $ cat read_inte_into_real.f90 program test implicit none real(kind=8) :: work(2) integer(kind=4) :: ier character(len=32) :: string ! string = "1 48216 0.10763 0.12938 0.05432 " read(string,'(I1,1X,I5)',iostat=ier) work if (ier.ne.0) then print *,"Error" else print *,work endif end program test $ ifort read_inte_into_real.f90 -o test && ./test 4.940656458412465E-324 2.382186917988154E-319

[Ron_Green]

I can see your point on this issue.

-check format

will catch this sort of mismatch.  This runtime check is not on by default but can be enabled with the option above.

Let me talk to the developers on this one.  Perhaps we can improve this.  

ron

[Sebastien_B_]

Thank you Ron for the feedback. I was not aware of this option and I will use it from now. However, I think it should be enabled by default since I don't see the point in returning incorrect values with no error, even if I understand that some people may want to disable this check.

[Izaak_Beekman]

I suspect the reason why this is not enabled by default, is that there is no way to check the input at compile time, and to check it at runtime requires linking against additional libraries and executes additional code, which has the potential to slow the program down. Enabling it by default would be a headache to most other users for this reason.

FWIW, I always compile with -warn (compile time warnings) and -traceback (very low expense to get call stack traces when something goes wrong) and the first time I run the code after editing/modifying/writing it, I enable all runtime checks with -check.

[FortranFan]

Izaak Beekman wrote:

...

FWIW, I always compile with -warn (compile time warnings) and -traceback (very low expense to get call stack traces when something goes wrong) and the first time I run the code after editing/modifying/writing it, I enable all runtime checks with -check.

Excellent suggestions.

[Steven_L_Intel1]

It is our extension that we allow free conversion among numeric types in formatted, list-directed and NAMELIST input. As Ron says, we have an option to disable this extension. The words in the standard are a requirement on the program, not the compiler. As Izaak says, this rule can't be checked at compile time.

[Sebastien_B_]

Steve Lionel (Intel) wrote:
It is our extension that we allow free conversion among numeric types in formatted, list-directed and NAMELIST input.

I am not sure to understand this point. Do you say that what I consider as a bug is a desired feature (extension) with a real use-case?

Steve Lionel (Intel) wrote:
As Ron says, we have an option to disable this extension. The words in the standard are a requirement on the program, not the compiler. As Izaak says, this rule can't be checked at compile time.

I also speak about the program behavior, i.e. checking the format and variable match at run-time. FYI, gfortran performs this test by default, so that my end-users experience is better/correct with gfortran (comprehensive error) than ifort (invalid result)...

[Steven_L_Intel1]

On reconsideration, this is probably not intentional. I was thinking of something different. Let me investigate further.

[Steven_L_Intel1]

Ok, here's what's going on. This is intentional behavior. The primary motivation was to support pre-F77 code that, typically, stored character data in numeric variables, reading and writing with A format. Curiously, while the standard is explicit in saying that the datatype "shall" be integer for I format, "shall" be real or complex for F,E,D,EN,ES, "shall" be logical for L, the word "shall" is not there for A format.

What we do here is read in the value as an integer and then store it to the variable as if it were an integer. For smaller integer values, this tends to end up looking like a denormalized real value. Correspondingly, on a write, we interpret the bits as an integer (for I format).

This extension is decades old and my guess is that the developers at the time chose to be "generous" in allowing mismatches, especially as programs of the time tended to do lots of weird things with mismatched types. It's a situation that has outlived its usefulness.

I have entered a feature request, issue DPD200361091, recommending that the default be changed to -check format so that these mismatches will be detected. Users who want to use the extension can restore the old behavior with -check noformat.

This is another example of compilers with a long history being more flexible than newer compilers that didn't grow up with very old programs.

[Sebastien_B_]

Steve Lionel (Intel) wrote:
Ok, here's what's going on. This is intentional behavior. The primary motivation was to support pre-F77 code that, typically, stored character data in numeric variables, reading and writing with A format. Curiously, while the standard is explicit in saying that the datatype "shall" be integer for I format, "shall" be real or complex for F,E,D,EN,ES, "shall" be logical for L, the word "shall" is not there for A format. What we do here is read in the value as an integer and then store it to the variable as if it were an integer. For smaller integer values, this tends to end up looking like a denormalized real value. Correspondingly, on a write, we interpret the bits as an integer (for I format).

Ok, I suspected something like this.

Steve Lionel (Intel) wrote:
This extension is decades old and my guess is that the developers at the time chose to be "generous" in allowing mismatches, especially as programs of the time tended to do lots of weird things with mismatched types. It's a situation that has outlived its usefulness. I have entered a feature request, issue DPD200361091, recommending that the default be changed to -check format so that these mismatches will be detected. Users who want to use the extension can restore the old behavior with -check noformat. This is another example of compilers with a long history being more flexible than newer compilers that didn't grow up with very old programs.

Indeed. Thank you Steve for this detailed analysis and future "improvement". For now I will enable "-check format" for my current version of ifort.