[Bug fortran/39587] New: Reading integer from "" gives end-of-file instead of reading a 0

[Bug fortran/39587] New: Reading integer from "" gives end-of-file instead of reading a 0

[burnus at gcc dot gnu dot org]

The following program works with NAG f95, g95, sunf95, ifort but fails with a
  Fortran runtime error: End of file
in gfortran. I think the program is valid.

---------------------------------
implicit none
character(len=5) :: str
integer :: a
str = ''
a = 5
read(str,'(5x,i1)') a
print *, a
if(a /= 0) call abort()
end
---------------------------------

If one uses a logical value rather than an integer, ifort/openf95/sunf95 print
.false. and g95/NAG f95/gfortran print an error.

I think "" -> .false. is a vendor extension. If I read the standard correctly,
this extension makes the compiler invalid (i.e. the compiler needs to diagnose
this rather than doing something else); however, I might be wrong and this
extension is acceptable.

I asked at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/68cb46bf0e610043

 * * *

See "10.6.1 Numeric editing": "On Input [...] A field containing only blanks is
considered to be zero."

(Such a statement is missing from "10.6.2 Logical editing".)

I did not quickly find the place which allows "" (rather than " ") to be 0 and
not end-of-file. I also did not find the place which requires the end-of-file
error rather allowing for .false.


-- 
           Summary: Reading integer from "" gives end-of-file instead of
                    reading a 0
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2009-03-30 20:31 -------
Steve Lionel thinks that compilers accepting "" for .false. are standard
conforming as they are not required to diagnose this. Thus, I would like to see
this extension in gfortran as well ;-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[jvdelisle at gcc dot gnu dot org]

------- Comment #2 from jvdelisle at gcc dot gnu dot org  2009-04-11 15:46 -------
I think gfortran has this right.  This is an attempt to read from an internal
unit of length zero.  Try the same operation from a zero length file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2009-04-14 08:09 -------
> I think gfortran has this right. This is an attempt to read from an internal
> unit of length zero.  Try the same operation from a zero length file.

I'm not sure whether gfortran is right, but my program from comment 0 works
with NAG f95, ifort, sunf95, openf95, g95, pathf95, pgf95 - and only fails with
gfortran.

The following program (using a zero-length file) works with all of the
compilers above - and it also works with gfortran:


implicit none
character(len=5) :: str
integer :: a
str = ''
a = 5
open(16,form='formatted')
write(16,'(a)') ''
rewind(16)
read(16,'(5x,i1)') a
close(16,status='delete')
print *, a
if(a /= 0) stop 'Error'
end

 * * *

The following  vendor extension  would be nice; it works with ifort, sunf95,
openf95, pgf95, pathf95:


implicit none
character(len=5) :: str
logical :: a
str = ''
a = .true.
read(str,'(L1)') a  ! Extension: Blanks are read as .false.
print *, a
if(a .neqv. .false.) stop 'error'
end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-04-15 02:16 -------
Without trying it. Your example is not a zero length file.  You have written at
least a LF or CR-LF.

I am not convinced yet.  I just want to know the basis.  Is this standard
conforming or is it an extension?  Is it consistent?  I have not add any time
lately to look at anything in detail.  The overwhelming majority is obviously a
clue. (Or is it?)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-04-27 11:58 -------
Regarding the reading of '(x5,i1)' from a too short string: I asked at c.l.f,
see
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bbe85b69b188f999

(My ceterum censeo:) Regarding the vendor extension of supporting reading a
logical ' ' as .false.: It would be nice and seems not to clash with the
standard - and I know a program using this extension...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2009-04-27 17:33 -------
Dick Hendrickson answered (see link above):

'It's scattered around, but the PAD= is the thing you want.
 In internal I/O it says it acts as if there were an OPEN
 without a PAD= specifier.  In the OPEN section it says the
 default for no PAD= is YES.  In 9.5.3.4.2 it finally says
 "During advancing input when the pad mode has the value YES,
 blank characters are supplied by the processor if the input
 list and format specification require more characters from the record
 than the record contains."

 So, the processor should supply extra blanks as needed.'

 * * *

Ceterum autem censeo ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[jvdelisle at gcc dot gnu dot org]

------- Comment #7 from jvdelisle at gcc dot gnu dot org  2009-04-29 03:38 -------
Notice what gfortran does with this modified from the original test case:

read(str,'(i1)') a

 ./a.out 
           0

Here we properly pad as expected.  Now, the subtlety here is: should we provide
positioning into a zero length file, into non existent space.  Seems absurd to
me. I understand the text that Dick is pointing out, but I do not believe the
standards committee implied that one can position a file past its end.

Notice the standard gives the condition "if an input item and its corresponding
data edit descriptor require more characters from the record than the record
contains."

The input item is the integer 'a', its corresponding edit descriptor is 'i1'

The original case is:

read(str,'(5x,i1)') a

'5x' is not the (singular) corresponding edit descriptor for the input item 'a'

'5x' is a control edit descriptor and not a data edit descriptor.

F2003 Standard 10.7.1  "The position specified by an X edit descriptor is
forward from the current position. On input, a position beyond the last
character of the record may be specified if no characters are transmitted from
such positions."

I will argue that we are attempting to transmit a character from such position
and therefore the original test case is invalid.

I also see that one could choose to interpret that since there are no
characters at this position, one is not attempting to read any, and indeed we
are not, therefore its OK to position past the end.

I will then counter it is a fact this is a read statement with a valid list
item, the integer 'a', this is indeed an attempt to transmit a character from
an invalid position.

Gads, I am not a lawyer.  However, by my argument, if I change the string to
contain 5 characters, the read should be valid with padding.  gfortran does not
get that part right.

So, we need to do something about this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2009-04-29 04:06 -------
Also, we need to consider taking F2003 9.10 at face value.  Notice the use of
the word "attempt":

"An end-of-file condition occurs in the following cases:

(1)  When an endfile record is encountered during the reading of a file
connected for sequential access.

(2) When an attempt is made to read a record beyond the end of an internal
file.

(3) When an attempt is made to read beyond the end of a stream file.

Number (2) seems to clearly apply and has nothing to do with padding.

Still, I want to think about this case:

implicit none
character(len=5) :: str
integer :: a
str = 'mnop '
a = 5
read(str,'(5x,i1)') a
print *, a
if(a /= 0) call abort()
end

I am inclined now to say gfortran is OK based on item (2) since we are clearly
attempting to read the character after the fifth position.  If we change the
length of the string to 6, padding kicks in.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587

[Bug fortran/39587] Reading integer from "" gives end-of-file instead of reading a 0

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2009-12-05 06:36 -------
No comments for a while, closing as won't fix.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587