Problem reading standard input from file

Hello,

program myread_cr.for

      integer*4 myint
      myint=0
      do while (mypos .ne. -10)
        read(*,'(I12)') mypos
        write(*,'(A,I12)') 'Entered: ',mypos
      enddo
      end

reads integers from standard input until -10 is entered. This works fine if compiling the executable with both the 32 bit and 64 bit version of Salford's ftn95. Now I would like to make executable myread_cr.exe read from input file input_file.txt instead of standard input. This may be done by command

myread_cr.exe <  input_file.txt

. For input_file.txt

0
120
-10

command 'myread_cr.exe < input_file.txt' crashes at runtime with error message

Silverfrost 64-bit exception report on c:\ds\samples\salford_8.50\myread_cr.EXE  Wed Dec 11 12:20:09 2019


Attempt to read past end-of-file at address 1c0086e1

Within file myread_cr.EXE
in MAIN@ in line 4, at address 7e


RAX = 0000000000000039   RBX = 0000000000000039   RCX = 0000000000000039   RDX = 0000000000000000
RBP = 000000001c000000   RSI = 0000000000000039   RDI = 0000000003f88fd0   RSP = 000000000240fac0
R8  = 000000000000009e   R9  = 000000000240f968   R10 = 00000000000f5d10   R11 = 000000000240f9e2
R12 = 0000000000000000   R13 = 0000000000000000   R14 = 0000000000000000   R15 = 0000000000000013

1c0086e1) int       9

. This is the case because the last line of input_file.txt (starting with -10) does not end with characters \r\n (CR LF). The other 2 lines end with \r\n.

This crash does **not **happen if compiling the executable with Salford's 32 bit version of ftn95 nor if using the INTEL 64 bit compiler.

If I add \r\n to the last line of input_file.txt, then everything is ok, as well, for the 64 bit version of SALFORD.

Note: when compiling myread_cr.for with ftn95 I did **not **use option '/windows'.

Regards, Dietmar

I will make a note and see what can be done.

In the mean time, you can use the end= or err= additions to the READ statement. This will allow you to intercept the conditions and not have the program crash (err= also handles bad data from humans!).

Thanks for your info, wahorger.

The err/end additions work, but my main intention was to show that the 64 bit and the 32 bit generated versions of the exe file behave different 😃 This should not be the case I think.

By the way, the end statement works but is not behaving the same for the 32 bit and the 64 bit generated exe file:

      integer*4 myint
      myint=0
      do while (myint .ne. -10)
        read(*,'(I12)',end=1000) myint
        write(*,'(A,I12)') 'Entered: ',myint
      enddo
1000  continue
      end

Output of 32 bit generated exe:

Entered:            4
Entered:           15
Entered:          -10

Output of the 64 bit generated exe:

Entered:            4
Entered:           15

Regards, Dietmar

Indeed, DietmarSiepmann, I see that now; my error for not reading all the way to the end to get your full intention. Apologies.

It looks as if the last line could be -10 <eof>, which is then treated differently by 32 and 64 bit. If you put a <cr> after -10, would that change the 64 bit response ?

I find this problem of not terminating the last line of data to produce variable results (which can occur using notepad). It may be that you need at least 12 characters or a terminating <cr> for 64 bit to not report an end of file or end of record error.

John,

you are right with your observations, I thought to have noted this in my entry at the beginning:

If I add \r\n to the last line of input_file.txt, then everything is ok, as well, for the 64 bit version of SALFORD.

.

My main intention was that in the cases mentioned the 32 bit generated exes did not behave in the same way as the 64 bit ones 😃

wahorger, thanks once again for your hint with the end addition in the read statement, which I indeed was not aware of 😃

Regards, Dietmar

This has now been fixed for the next release (after v8.61).

The missing line feed on the last line of the input file might be expected to lead to an EOF error but this is not consistent with the result for 32 bit code.