[Bug fortran/107031] New: endfile truncates file at wrong position

[Bug fortran/107031] New: endfile truncates file at wrong position

[kishore96 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

            Bug ID: 107031
           Summary: endfile truncates file at wrong position
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kishore96 at gmail dot com
  Target Milestone: ---

SUMMARY
-------
When `endfile` is used to truncate a file after a read statement, gfortran
wrongly inserts end-of-file after the next line, rather than after the current
line.

STEPS TO REPRODUCE
------------------
1. create the following program, truncate.f90:
```fortran
program test_truncate
    integer :: num_rec, tmp, i, ioerr

    open(1, file="in.dat", action='readwrite')

    num_rec = 5
    i = 1
    ioerr = 0
    do while (i <= num_rec .and. ioerr == 0)
        read(1, *, iostat=ioerr) tmp
        i = i+1
    enddo

    !backspace(1)
    endfile(1)
    close(1)
end program test_truncate
```

2. Create the following text file, `in.dat`
```
1
2
3
4
5
6
7
8
9
10
```

3. Compile the program: `gfortran truncate.f90`

4. Run the program: `./a.out`

OBSERVED RESULTS
----------------
```bash
$cat in.dat
1
2
3
4
5
6
```

EXPECTED RESULTS
----------------
```bash
$cat in.dat
1
2
3
4
5
```

Since after the end of the loop, the current record is `5`, one would expect
endfile to write an end-of-file record as the next record (e.g.
<https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn8v/index.html>), leading
to the result above.

SOFTWARE VERSIONS
-----------------
OS: Arch Linux
gfortran: 12.2.0


ADDITIONAL INFORMATION
----------------------
Intel ifort (version 19.0.5.281 20190815) produces the expected result.

May be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52387, but I
think not, since my example program doesn't use nonadvancing reads anywhere.

Uncommenting the `backspace(1)` gives output
```bash
$cat in.dat
1
2
3
4
```

[Bug libfortran/107031] endfile truncates file at wrong position

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |libfortran
     Ever confirmed|0                           |1
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-09-25

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

It appears that this issue exists since 2005.

[Bug libfortran/107031] endfile truncates file at wrong position

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
             Status|NEW                         |WAITING

--- Comment #2 from kargl at gcc dot gnu.org ---
gfortran's current behavior is correct.


   12.3.4.4 File position after data transfer

   In all other cases, the file is positioned after the record just
   read or written and that record becomes the preceding record.

   12.8.3 ENDFILE statement

   Execution of an ENDFILE statement for a file connected for sequential
   access writes an endfile record as the next record of the file.

After reading '5', the file is position at the record that contains '6'.
So, ENDIFLE writes the endfile record after the record with '6'.

[Bug libfortran/107031] endfile truncates file at wrong position

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> gfortran's current behavior is correct.
> 
> 
>    12.3.4.4 File position after data transfer
> 
>    In all other cases, the file is positioned after the record just
>    read or written and that record becomes the preceding record.
> 
>    12.8.3 ENDFILE statement
> 
>    Execution of an ENDFILE statement for a file connected for sequential
>    access writes an endfile record as the next record of the file.
> 
> After reading '5', the file is position at the record that contains '6'.
> So, ENDIFLE writes the endfile record after the record with '6'.

Hmm, interpretation of text?

I read "as the next record", not "after the next record".

gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn.

[Bug libfortran/107031] endfile truncates file at wrong position

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> (In reply to kargl from comment #2)
> > gfortran's current behavior is correct.
> > 
> > 
> >    12.3.4.4 File position after data transfer
> > 
> >    In all other cases, the file is positioned after the record just
> >    read or written and that record becomes the preceding record.
> > 
> >    12.8.3 ENDFILE statement
> > 
> >    Execution of an ENDFILE statement for a file connected for sequential
> >    access writes an endfile record as the next record of the file.
> > 
> > After reading '5', the file is position at the record that contains '6'.
> > So, ENDIFLE writes the endfile record after the record with '6'.
> 
> Hmm, interpretation of text?
> 
> I read "as the next record", not "after the next record".
> 
> gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn.

If the current record contain '6', the next record contains '7'.
'next' does not mean 'current' in the English language.  It means
something that 'follows'.

[Bug libfortran/107031] endfile truncates file at wrong position

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Sep 25, 2022 at 08:56:22PM +0000, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
> 
> --- Comment #4 from kargl at gcc dot gnu.org ---
> (In reply to anlauf from comment #3)
> > (In reply to kargl from comment #2)
> > > gfortran's current behavior is correct.
> > > 
> > > 
> > >    12.3.4.4 File position after data transfer
> > > 
> > >    In all other cases, the file is positioned after the record just
> > >    read or written and that record becomes the preceding record.
> > > 
> > >    12.8.3 ENDFILE statement
> > > 
> > >    Execution of an ENDFILE statement for a file connected for sequential
> > >    access writes an endfile record as the next record of the file.
> > > 
> > > After reading '5', the file is position at the record that contains '6'.
> > > So, ENDIFLE writes the endfile record after the record with '6'.
> > 
> > Hmm, interpretation of text?
> > 
> > I read "as the next record", not "after the next record".
> > 
> > gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn.
> 
> If the current record contain '6', the next record contains '7'.
> 'next' does not mean 'current' in the English language.  It means
> something that 'follows'.
> 

Further confusion, maybe?

12.3.4 File position

12.3.4.1 General
...
Let n be the number of records in the file.
...
If 1 <= i < n and a file is positioned within the ith record or
between the ith and (i + 1)th record, the (i + 1)th record is the
next record.

[Bug libfortran/107031] endfile truncates file at wrong position

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> (In reply to kargl from comment #2)
> > gfortran's current behavior is correct.
> > 
> > 
> >    12.3.4.4 File position after data transfer
> > 
> >    In all other cases, the file is positioned after the record just
> >    read or written and that record becomes the preceding record.
> > 
> >    12.8.3 ENDFILE statement
> > 
> >    Execution of an ENDFILE statement for a file connected for sequential
> >    access writes an endfile record as the next record of the file.
> > 
> > After reading '5', the file is position at the record that contains '6'.
> > So, ENDIFLE writes the endfile record after the record with '6'.
> 
> Hmm, interpretation of text?
> 
 Yes, it is interpretation.

Let <R> denote the start of record and </R> the end of the record.
One has 

<R>5</R><R>6</R><R>7</R>

After reading '5', the file is positioned to after that record.  If * denotes
the current file, then one can have

<R>5</R>*<R>6</R> or <R>5</R><R>*6</R>

Both meet the requirement of 12.3.4.4. Now by 12.8.3, the endfile will give

<R>5</R>EOF

while the latter would give

<R>5</R><R>*6</R>EOF.

[Bug libfortran/107031] endfile truncates file at wrong position

[urbanjost at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

urbanjost at comcast dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |urbanjost at comcast dot net

--- Comment #7 from urbanjost at comcast dot net ---
FYI:  A parallel discussion of this issue came to the consensus that the file
should be truncating to five lines, not six. The conversation included members
of the Fortran Standards Committee. 



https://fortran-lang.discourse.group/t/clarification-on-expected-behavior-of-endfile/

[Bug libfortran/107031] endfile truncates file at wrong position

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org
                 CC|                            |jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Thankyou for information, I will take a look.

[Bug libfortran/107031] endfile truncates file at wrong position

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
The following trivial patch changes gfortran behavior and regression tests Ok
on x86_64.

I will see if I can come up with a test case to catch this.

diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c
index 2bc05b293f8..d169961f997 100644
--- a/libgfortran/io/file_pos.c
+++ b/libgfortran/io/file_pos.c
@@ -352,7 +352,6 @@ st_endfile (st_parameter_filepos *fpp)
          dtp.common = fpp->common;
          memset (&dtp.u.p, 0, sizeof (dtp.u.p));
          dtp.u.p.current_unit = u;
-         next_record (&dtp, 1);
        }

       unit_truncate (u, stell (u->s), &fpp->common);

[Bug libfortran/107031] endfile truncates file at wrong position

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>:

https://gcc.gnu.org/g:41e767c482fc903ca5d54014b034c7526dbf8f1c

commit r14-9681-g41e767c482fc903ca5d54014b034c7526dbf8f1c
Author: Jerry DeLisle <jvdelisle@gcc.gnu.org>
Date:   Tue Mar 26 16:44:17 2024 -0700

    libgfortran: Fix file position after ENDFILE statement.

            PR libfortran/107031

    libgfortran/ChangeLog:

            * io/file_pos.c (st_endfile): Remove call to next_record().

    gcc/testsuite/ChangeLog:

            * gfortran.dg/endfile_5.f90: New test.

[Bug libfortran/107031] endfile truncates file at wrong position

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Fixed on trunk, closing.