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 

Compiler bug: allows REC= writing sequential file

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Jan 24, 2015 5:22 pm    Post subject: Compiler bug: allows REC= writing sequential file Reply with quote

There is a bug exposed in a recent thread: http://forums.silverfrost.com/viewtopic.php?t=2992

Whereas that thread is about slow performance, the bug that I wish to report is as follows. For a file opened for sequential unformatted access the rules do not admit a REC= clause in a WRITE statement to that file, according to the F95 and later standards.
Quote:
9.4.1.3 Record number
The REC= specifier specifies the number of the record that is to be read or written. This specifier
may be present only in an input/output statement that specifies a unit connected for direct access.

FTN95 7.1 does not enforce this rule. The following test program, which violates this rule and opens the file without RECL=, goes haywire and creates a huge output file of 65,534,000 bytes, a plausible reason being that the record length was never specified and a garbage value is being used. No runtime I/O error is reported, even after using /CHECK.
Code:
PROGRAM main
character iorecord(194)
character*20 access,form
!
access = 'sequential'
form = 'unformatted'
max_recs=2000
open(unit=15,file='testfile.dat',access=access,&
     form=form,status='replace')
call randomfile(iorecord,194) ! content of records should not matter,
                              ! so set all to the same value
!write records 1,3,5,...
do i=1,max_recs,2
   write(15,rec=i)iorecord
end do
!write records 2,4,6,...
do i=2,max_recs,2
   write(15,rec=i)iorecord(1:97)
end do

print *,'For access=',access,' format=',form
close(unit=15)
stop

END PROGRAM main
subroutine randomfile(iorecord,length)
character*1 iorecord(length)
do i=1,length
  iorecord(i)=char(mod(7*i-3,256))
end do
return
end


[P.S., 15 June 2015: A runtime error, #90, "File access and properties are incompatible", is issued when this program is compiled with FTN95 7.20]


Last edited by mecej4 on Mon Jun 15, 2015 11:53 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Jan 26, 2015 8:44 am    Post subject: Reply with quote

Thank you for this. I have logged it for investigation.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Wed Feb 04, 2015 4:48 pm    Post subject: Reply with quote

This has now been fixed for the next release.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Feb 04, 2015 4:56 pm    Post subject: Reply with quote

Thanks, Paul.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Jul 12, 2016 11:07 am    Post subject: Reply with quote

I have a comment here (after reading this post in relation to the other post which inspired it).

Noing mecej4's edited post comment of June 2015:-

Quote:
[P.S., 15 June 2015: A runtime error, #90, "File access and properties are incompatible", is issued when this program is compiled with FTN95 7.20]


I assume this is the 'fix' which was made.

My question is, why isn't a much more user-friendly message issued which reflects more precisely the error, for example such as:-

"... runtime error, #90, "RECL= has been specified in error in the OPEN statement for a SEQUENTIAL Access file (Unit <unit number here>) when It is only allowed for opening a file connected for DIRECT access. "

or somesuch, thus saving the unfortunate user the sometimes 'Dan-esque' Wink type 'devil torture' trying to decipher less-than-intuitive error messages !?!

I'm not intending to be over-critical for the sake of it here, but the quite regular posts concerning error messages which are less than helpful doesn't seem to be gaining much ground.
Maybe it's just that there's a technical reason why error messages are so short & obscure sometimes ? ... or just something they put in programmer's cornflakes for breakfast Wink
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jul 12, 2016 1:01 pm    Post subject: Reply with quote

I am not sure how to respond to respond to this. Maybe I will just count to 10 or perhaps more...
Back to top
View user's profile Send private message AIM Address
simon



Joined: 05 Jul 2006
Posts: 268

PostPosted: Sat Jul 16, 2016 10:19 pm    Post subject: Reply with quote

Good response Paul! When you've stopped counting maybe you could add in an option to get FTN95 to compile what the programmer intends rather than what (s)he actually codes!

It's the easiest thing for the programmer to write an error message that (s)he would have found more useful, post hoc. But in the case in question, how is the compiler to know that the ACCESS was correct and the RECL incorrect? It could just as easily have been the other way around, or that both were incorrect. Do we want a compiler that gives us a long list of all possible errors that could have been made?
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Jul 18, 2016 9:44 am    Post subject: Reply with quote

I guess the long answer is .... YES ! Wink
(come on Dan, back me up here against these 'devils' ! Smile )
if not in the compiler message itself then at least somewhere in the manual(s) where there's an explication of runtime error ̣his case) instead of jus ta simple replication of the issued error message with no explication !!!
... where is the list of runtime errors anyway in the documentation, I've never come across it ?


As for Paul's counting quandry (or maybe that should be conundrum), well 10 is right out, as ALL programmers should know as they should be well acquainted with the Python programmers reference video series .....

https://www.youtube.com/watch?v=xOrgLj9lOwk&spfreload=10

darn programmers !

P.S.
Quote:
maybe you could add in an option to get FTN95 to compile what the programmer intends rather than what (s)he actually codes!


... but I thought that was what the 'optimisation' compile option built into ftn95 does - isn't it Wink

P.P.S.
it should be the holy hand grenade of 'the short and obscure' .
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Jul 18, 2016 7:54 pm    Post subject: Reply with quote

There is a long list of runtime error numbers in the FTN77 documentation.

No list of compile time errors though.
Back to top
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Thu Jul 21, 2016 12:24 pm    Post subject: Reply with quote

Ah yes, meaningful error messages. In the olden days I used a system called "Maximop" at Sunderland Poly on their ICL 1903 computer. When a Fortran program crashed there, it gave the useful message:
"Forced to close your files"
And after issuing the next operating system command the dialogue went something like (Uppercase for user commands):

ED FRED.FOR
You cannot issue that command when you are not logged on.
LOGON MYUSERNAME
You cannot log on when you have not logged off.
LOGOFF
You cannot log off when you are not logged on.
LOGON MYUSERNAME
You cannot log on when you have not logged off.
LOGOFF
You cannot log off when you are not logged on.
GRRRRRRRRRRRRRRRRRR, (gnashing of teeth and looking for a hammer)

Fortunately there was a solution
LOGON MYUSERNAME,MYPASSWORD


You lot don't know you are born. LOL
Back to top
View user's profile Send private message Send e-mail
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Thu Jul 21, 2016 12:24 pm    Post subject: Reply with quote

Ah yes, meaningful error messages. In the olden days I used a system called "Maximop" at Sunderland Poly on their ICL 1903 computer. When a Fortran program crashed there, it gave the useful message:
"Forced to close your files"
And after issuing the next operating system command the dialogue went something like (Uppercase for user commands):

ED FRED.FOR
You cannot issue that command when you are not logged on.
LOGON MYUSERNAME
You cannot log on when you have not logged off.
LOGOFF
You cannot log off when you are not logged on.
LOGON MYUSERNAME
You cannot log on when you have not logged off.
LOGOFF
You cannot log off when you are not logged on.
GRRRRRRRRRRRRRRRRRR, (gnashing of teeth and looking for a hammer)

Fortunately there was a solution
LOGON MYUSERNAME,MYPASSWORD


You lot don't know you are born. LOL
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support 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