Missing Exponent Bug in READ Statement

[aarograh]

I believe I've found what appears to be a bug in the ifx implementation of the READ statement.  Here is example code:

PROGRAM string_bug

CHARACTER(LEN=:),ALLOCATABLE :: str
INTEGER :: ioerr
REAL :: x

str = '0.123e'
READ(str,*,IOSTAT=ioerr) x
WRITE(*,*) '"'//str//'"', x, ioerr

ENDPROGRAM string_bug

Compiling and executing with

ifx -c string_bug.f90
ifx string_bug.o -o string_bug.exe
./string_bug.exe

gives this result:

"0.123e" 0.1230000 0

Doing the same with gfortran instead of ifx gives the following result:

"0.123e" 4.63465438E+19 5010

My project supports multiple compilers, which is how I came across this issue.  After some investigation, I've found Section 10.6.1.2.1 of the Fortran 2003 standard, titled "F editing", under 10.6 "Data edit descriptors" under section 10 "Input/output editing" (note: it's a "Working Draft" PDF from May 2004, so some of the number may be different in the final version; I don't have the final).  This section states the following in describing the format of values edited with the `F` descriptor:

The basic form may be followed by an exponent of one of the following forms:
  (1) A sign followed by a digit-string
  (2) E followed by zero or more blanks, followed by a signed-digit-string
  (3) D followed by zero or more blanks, followed by a signed-digit-string

Based on my own interpretation of this, it seems that the gfortran approach is more in line with the standard, since the standard does not seem to allow for an `e` with no numbers after it.  ifx seems to be more lenient and "assumes" that `e` is meant to be `e0`.

Can anyone comment on whether I've understood the standard properly and whether this should be considered a bug in ifx?

Here's my compiler/system information:

$ cat /proc/version
Linux version 5.15.153.1-microsoft-standard-WSL2 (root@941d701f84f1) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Fri Mar 29 23:14:13 UTC 2024
$ ifx --version
ifx (IFX) 2024.2.1 20240711
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

[Ron_Green]

Your program is not using the F edit descriptor.  You are using List Directed IO, "*".  The format is therefore defined by the computer system at the moment the statement is executed.  List Directed IO does vary by implementation.  

Given our large numbers of existing users with legacy applications, yes, we tend to be more lenient in our List Directed IO.  Not a bug, it's a feature.

[aarograh]

I'm not convinced.  The section on List Directed IO contains the following:

"When the next effective item is of type real, the input form is that of a numeric input field. A numeric input field is a field suitable for F editing (10.6.1.2.1) that is assumed to have no fractional digits unless a decimal symbol appears within the field."

It literally points right back to the section I originally referenced when defining valid input for a numeric, non-integer input field.  So if the F descriptor says that 

'0.123e'

is an invalid input, then the List Directed IO says the same.

---