Compiler bug: allows REC= writing sequential file

There is a bug exposed in a recent thread: https://forums.silverfrost.com/Forum/Topic/2648

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.

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.

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]

Thank you for this. I have logged it for investigation.

This has now been fixed for the next release.

Thanks, Paul.

I am not sure how to respond to respond to this. Maybe I will just count to 10 or perhaps more...

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?

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

No list of compile time errors though.

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

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