Backspace

[Neil]

Hello,

I get different behaviour with different compilers (gfortran and
nagfor on the one hand and ifort (OneAPI) on the other) for a very
simple example featuring the backspace command:

pyb075000011:~/Problem> cat x.f90
PROGRAM x
IMPLICIT NONE
INTEGER :: ierr,tempi
CHARACTER(80) :: char_80
OPEN(8,file='y.dat')
READ(8,*,iostat=ierr)tempi
IF(ierr/=0)BACKSPACE 8
READ(8,'(a)')char_80
WRITE(*,*)trim(char_80)
CLOSE(8)
END PROGRAM x

pyb075000011:~/Problem> cat y.dat
A B
C D

pyb075000011:~/Problem> gfortran --version
GNU Fortran (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

pyb075000011:~/Problem> gfortran x.f90

pyb075000011:~/Problem> ./a.out
A B

pyb075000011:~/Problem> nagfor x.f90
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101
Questionable: x.f90, line 11: Variable TEMPI set but never referenced
[NAG Fortran Compiler normal termination, 1 warning]

pyb075000011:~/Problem> ./a.out
A B

pyb075000011:~/Problem> ifort --version
ifort (IFORT) 2021.8.0 20221119
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

pyb075000011:~/Problem> ifort x.f90

pyb075000011:~/Problem> ./a.out
C D


gfortran and nagfor give the result I would expect. I was wondering
if there is a problem with the Fortran code, or is it an issue with
ifort?


Thanks,

Neil.

[CyrMag]

When the OPEN statement does not specify a POSITION, the file is opened with POSITION='ASIS'. The initial position of the file that corresponds to 'ASIS' is processor dependent.
If you want a specific position to be reached before reading, make sure to specify using the POSITION clause, or take other steps (such as reading) to reach the desired position.

-CyrMag

[Arjen Markus]

I have tried your program as is, with Intel Fortran oneAPI on WIndows and Linux, and got the expected result. The version were not exactly the version you report, but there does not seem anything wrong.

Could you try with another version?

Regards,

Arjen

[Keith Refson]

You might want to take a look at the thread in the Intel Forums

https://community.intel.com/t5/Intel-Fortran-Compiler/Regression-with-quot-backspace-quot-in-2023-0/td-p/1440534

The behaviour of "backspace" following an I/O error is undefined, and although every compiler I have ever tried (incl cray, NAG, PGI, Intel, GNU and more) have implemented the obvious extension behaviour of backing up to the beginning of he record, starting with oneAPI 2023.0, ifort behaviour is indeed undefined.

KR

[Neil]

Thanks very much for your replies and for the link to the recent
thread on Intel's forum.

I had not encountered this issue before, including with previous
versions of ifort (over decades).

I would have thought that backtracking after an error reading a line
would be one of the major uses of the backspace command.

I guess I will have to change my program to read lines into strings
and then read from those strings.

Thanks,

Neil.

[gah4]

On Friday, February 24, 2023 at 9:27:54 AM UTC-8, Keith Refson wrote:
> You might want to take a look at the thread in the Intel Forums
>
> https://community.intel.com/t5/Intel-Fortran-Compiler/Regression-with-quot-backspace-quot-in-2023-0/td-p/1440534
>
> The behaviour of "backspace" following an I/O error is undefined, and although every compiler I have ever tried
> (incl cray, NAG, PGI, Intel, GNU and more) have implemented the obvious extension behaviour of backing up to
> the beginning of he record, starting with oneAPI 2023.0, ifort behaviour is indeed undefined.

I thought it was also undefined after list-directed I/O.

Well, list-directed can use an unknown, to the programmer, number of records.

If you want to check, using actual FORMAT might be nice.

[CyrMag]

On Friday, February 24, 2023 at 12:30:31 PM UTC-6, Neil wrote:
> Thanks very much for your replies and for the link to the recent
> thread on Intel's forum.
>
> I had not encountered this issue before, including with previous
> versions of ifort (over decades).
>
> I would have thought that backtracking after an error reading a line
> would be one of the major uses of the backspace command.
>
> I guess I will have to change my program to read lines into strings
> and then read from those strings.
>
> Thanks,
>
> Neil.

Simply add POSITION='REWIND' to the OPEN statement, or add a REWIND statement. Backspacing is not the issue; rather, it is the unspecified initial position in the file.

-- CyrMag

[gah4]

On Friday, February 24, 2023 at 7:42:52 AM UTC-8, Neil wrote:

> I get different behaviour with different compilers (gfortran and
> nagfor on the one hand and ifort (OneAPI) on the other) for a very
> simple example featuring the backspace command:

12.8.2:

" Backspacing over records written using list-directed or namelist formatting is prohibited."

[David Jones]

Neil wrote:

>
> Thanks very much for your replies and for the link to the recent
> thread on Intel's forum.
>
> I had not encountered this issue before, including with previous
> versions of ifort (over decades).
>
> I would have thought that backtracking after an error reading a line
> would be one of the major uses of the backspace command.
>
> I guess I will have to change my program to read lines into strings
> and then read from those strings.
>

This last approach has the advantage that, if or when an error occurs,
you can write out exactly the line of input causing the problem,
allowing the input file to be debugged. Additionally, my experience, on
systems where BACKSPACE did work, was that this was rather slow.

[Ron Shepard]

This seems to me to be a very strange and overly broad restriction. Even
if records had been written with list-directed or namelist i/o, in the
end, they are just records in a file: strings of characters with line
separators. It seems like one should be able to use normal i/o
operations thereafter on those records. In fact, for an old file, one
might not even know exactly how some of the records had been written
(text editor, shell script, C program, fortran program, etc.). But this
restriction implies that once written by fortran list-directed i/o, they
are tainted forever after, even through multiple open and close
statements or even if opened at some time later in a completely
different program.

$.02 -Ron Shepard

[Neil]

> Simply add POSITION='REWIND' to the OPEN statement, or add a REWIND
> statement. Backspacing is not the issue; rather, it is the
> unspecified initial position in the file.

Thanks very much for the suggestion, but unfortunately this doesn't
change the observed behaviour (the difference between compilers).
(Also, I would prefer to fix the issue so that the outcome is
guaranteed by the Fortran standard.)

It would be helpful if compilers were to issue warnings or error
messages about undefined behaviour due to the use of backspace.

CyrMag <cyr...@gmail.com> wrote:

[gah4]

On Saturday, February 25, 2023 at 7:05:37 AM UTC-8, Ron Shepard wrote:

(snip)

> > 12.8.2:

> > " Backspacing over records written using list-directed or namelist formatting is prohibited."

> This seems to me to be a very strange and overly broad restriction. Even
> if records had been written with list-directed or namelist i/o, in the
> end, they are just records in a file: strings of characters with line
> separators. It seems like one should be able to use normal i/o
> operations thereafter on those records. In fact, for an old file, one
> might not even know exactly how some of the records had been written
> (text editor, shell script, C program, fortran program, etc.). But this
> restriction implies that once written by fortran list-directed i/o, they
> are tainted forever after, even through multiple open and close
> statements or even if opened at some time later in a completely
> different program.

In the case of an actual FORMAT, either a FORMAT statement,
or string constant or variable, the number of records written
by a WRITE statement, or read by a READ statement is known.
(Might be variable with implied-DO, but the variable is known.)

In the case of NAMELIST or list-directed, it isn't.

The standard is a little broader than it could be, but not much.
To be less broad, it would have to define exactly the cases where
you could, and could not, depend on the number of records.
(I believe that WRITE(*,*), and READ(*,*) reliable write and read
one record. Past that, you can't say much.)

Reminds me in Fortran 77 (and VAX/VMS) days, I was reading
in some X, Y data.

READ(5,1,END=2) (X(I), Y(I), I=1,N)

and expecting N to be one more than the number of items read.
In actual DO loops, the DO variable keeps its value when it leaves
the loop. Seems like it should for implied-DO. I even had a
blank DEC bug report form to fill out.

But the standard doesn't require that.

[John]

program x
implicit none
integer :: iostat,tempi,lun
character(len=256) :: iomsg
character(80) :: char_80
! create file
open (newunit=lun, file='y.dat', position='rewind', status='replace')
write (lun, '(a)') 'A B','C D'
rewind (unit=lun, iostat=iostat)

! once get an "error" position is undefined
read(lun,*,iostat=iostat,iomsg=iomsg)tempi
if(iostat /= 0)then
! if end-of-file define position to clear error
open (unit=lun, file='y.dat', position='asis')
backspace lun
endif
read(lun,'(a)')char_80
write(*,*)trim(char_80)
close(lun,iostat=iostat,status='delete')
end program x

[Thomas Koenig]

Neil <nddtwe...@gmail.com> schrieb:

> It would be helpful if compilers were to issue warnings or error
> messages about undefined behaviour due to the use of backspace.

I concur (at least in principle).

It would probably not be a good idea for existing compilers to
deviate from the existing practice without any options because
that would break existing programs, though...

For gfortran, a possibility would be to issue an error with
-pedantic when BACKSPACE is executed with a previous error.

This would be a fairly easy project for somebody willing to make
a contribution - the library is relatively straightforward C code.

[John]

[John]

Doing an OPEN statement without a CLOSE with POSITION='ASIS' worked with gfortran and ifort; but like with a lot of I/O issues it is hard to say if that is defined to work by the standard or just happens to cause ifort to get the expected behavior in the 2023 release. I cannot find anything that says it should not work; but I have actually never used POSITION='ASIS' in modern Fortran, although I used that type of behavior on older machines where multiple programs could read through a file sequentially where each started where the last left off; but I do not know if any platform still supports that.