forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problem reading standard input from file

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 183

PostPosted: Wed Dec 11, 2019 1:00 pm    Post subject: Problem reading standard input from file Reply with quote

Hello,

program myread_cr.for
Code:

      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
Code:

myread_cr.exe <  input_file.txt

. For input_file.txt
Code:

0
120
-10

command "myread_cr.exe < input_file.txt" crashes at runtime with error message
Code:
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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6097
Location: Salford, UK

PostPosted: Wed Dec 11, 2019 3:19 pm    Post subject: Reply with quote

I will make a note and see what can be done.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 666
Location: Morrison, CO, USA

PostPosted: Wed Dec 11, 2019 11:57 pm    Post subject: Reply with quote

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!).
Back to top
View user's profile Send private message Visit poster's website
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 183

PostPosted: Thu Dec 12, 2019 10:59 am    Post subject: Reply with quote

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 Smile 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:

Code:

      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:
Code:

Entered:            4
Entered:           15
Entered:          -10

Output of the 64 bit generated exe:
Code:

Entered:            4
Entered:           15


Regards,
Dietmar
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 666
Location: Morrison, CO, USA

PostPosted: Thu Dec 12, 2019 12:49 pm    Post subject: Reply with quote

Indeed, DietmarSiepmann, I see that now; my error for not reading all the way to the end to get your full intention. Apologies.
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2147
Location: Sydney

PostPosted: Thu Dec 12, 2019 11:45 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 183

PostPosted: Fri Dec 13, 2019 9:29 am    Post subject: Reply with quote

John,

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

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 Smile

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

Regards,
Dietmar
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group