Error in formatted read of real value goes unreported

I created a small test program to check what FTN95 does when a formatted read is attempted using E10.2 as the format when the input field does not contain a decimal point, and the file being read has been opened with BLANK = 'ZERO'.

program dread
implicit none
integer ios
real anin
character(18) :: str = 'ANIN   =4e19      '
character(200) msg
!
open(10,file = 'inpi.txt', status = 'replace')
write(10,'(A)')str
close(10)

open(11, file='inpi.txt', status='old', blank='zero')
read(11,'(8x,e10.2)', iostat = ios, iomsg = msg) anin
if (ios /= 0) then
   print *, 'IOSTAT = ', ios
   print *, msg
else
   print '(ES15.8)', anin
endif
close(11)
end

With FTN95, the output is

 0.00000000E+00

Other compilers give IOSTAT different from zero, and a corresponding message. I think that IOSTAT should be different from zero, after reading section 13.7.2.3.2 of the F2018 standard, but I am somewhat uncertain.

This test problem arose from DanRRight's recent post, https://forums.silverfrost.com/Forum/Topic/4137 .

mecej4

Thank you for the feedback. I will make a note that this needs investigating.

There's a list of IOSTAT values and their meanings in the FTN77 manual. Are they the same in FTN95? IOMSG looks useful - is there a list of those too?

Eddie

Is the problem that IOSTAT = 0 ? ie the error was not detected ?

program dread
implicit none
integer ios
real anin
character(18) :: str = 'ANIN   =4e19      '
character(200) msg
character a8*8, a10*10
!
open(10,file = 'inpi.txt', status = 'replace')
write(10,'(A)')str
close(10)

open(11, file='inpi.txt', status='old', blank='zero')
read(11,'(8x,e10.2,10x,i2)', iostat = ios, iomsg = msg) anin
if (ios /= 0) then
   print *, 'IOSTAT = ', ios
   print *, msg
else
   print '(ES15.8)', anin
   print *, 'IOSTAT = ', ios
   print *, msg
endif

rewind 11
read (11,'(a8,a10)') a8, a10
write (*,*) a8
write (*,*) a10

read (a10,'(e10.0)') anin
   print '(a,ES15.8)', 'anin = ',anin
close(11)
end

Eddie

The following code runs successfully using either FTN77 or FTN95...

      INTEGER*2 n
      CHARACTER*128 msg
C Current upper limit is 451 for FTN95.
      do 100 n = 1,447 
        CALL FORTRAN_ERROR_MESSAGE@(n, msg)
        PRINT*, msg
 100  continue  
      END

Hi Paul,

That's a useful facility, but they are, after all, Fortran error messages, not IO error messages. I was a bit confused by the 451*, as the sensible messages do stop at 447.

I paraphrased mecej4 and JC's demos down to this (in old-style):

      PROGRAM DR
      CHARACTER*(200) MSG
      OPEN   (10, FILE='ABCD.DAT', STATUS='REPLACE')
      WRITE  (10,*) '1.0'
      REWIND (10)
      READ   (10, '(I3)', IOSTAT = N1, IOMSG = MSG) I
      WRITE  (*,*) ' IOSTAT = ', N1, ' message = ', MSG
      END

Aha! It gives IOSTAT of 52, and the IOMSG is exactly the same as in the list in the FTN77 guide. Does the FTN95 list of IOSTAT numbers and their meanings still stop at 191** (or are there any more)? I'll assume that they are the same in FTN95 as in FTN77. Assuming that I didn't know about the FTN77 guide (and was also ignorant of IOMSG=, which is a fair assumption until educated by mecej4), where would I look in FTN95 documentation for the equivalent list?

Reverting to those Fortran error messages, where do I find the equivalent list in the documentation (and do I have to, now that I have been told how to generate my own, personal, list)? Presumably the FTN77 list is shorter, given that FTN95 has an expanded range of facilities that it is possible to get wrong, so is it true that there are 447 of the tricky blighters in FTN77?

Eddie

*As it appears, with my knowledge of it solely courtesy of Ray Bradbury, that paper burns at Fahrenheit 451, is that a super-clue that there isn't a paper version? Just asking.

**Will there be 192 once you've fixed mecej4's issue?

Eddie

451 is the upper limit for FTN95 whilst 447 is for FTN77.

The IOstat value is the index in the list of FTN95/FTN77 runtime errors.

Paul,

I got hieroglyphics when I upped the limit to 451 in your demo.

Eddie

Eddie

The upper limit for FTN95 relates to the latest version of the DLLs.

Paul's program above, modified to reach up to n = 451, gives 'hieroglyphics' for n = 448 to 451 when compiled for 32 bit. With /64, the messages are:

 448  Value returned by INQUIRE POS=ivalue will cause overflow. Use higher KIND
 449  Missing NEW_LINE at end of STREAM record
 450  The given POS value does not match the start of a STREAM record
 451  Memory corrupted before call to LEN_TRIM  

Ah! That explains it.

Still doesn't tell me where to look for the documentation though.

Eddie

In the FTN95 help file (ftn95.chm), look for the title 'Execution errors and IOSTAT values'. That will take you to a list of 447 error messages. There are four more newly added messages that are yet to make their way into the CHM file.

The online help at https://silverfrost.com/ftn95-help/asm/error_messages.aspx appears to have become corrupted. The title says 'Error Messages', but the subtitles have to do with assembler, CODE..EDOC, etc.

Eddie

You and mecej4 are right. The list for 32 bit FTN95 is not up to date.

It turns out to relate to a part of the FTN95 build process that I was unaware of. Either that or I had totally forgotten it.

The list is in ftn95.chm under Program development->Run time diagnostics->Excecution errors and IOSTAT values.

Got it, thanks.

Then I do think that the entry under 'Execution errors and IOSTAT values ought to be complemented by a line that says that the text from the table corresponding to a particular IOSTAT returned value can be retrieved with IOMSG=

I always shied away from IOSTAT because the return values are different for every compiler, although settling for FTN95 'until death do us part' makes that less of a consideration nowadays.

A disadvantage of running with a licensed version as against the PE is that the costs of upgrading militate against acquiring every single version update, and although some files and DLLs are provided for download, they don't include the CHM helpfile. It is also the case that many of the updates and bug fixes are in parts of the compiler that I probably never use, which is a factor in not updating every version as well as a Shylockian parsimony on my part.

Thanks both for the enlightenments.

Eddie

The original failure reported by mecej4 on this thread has now been fixed for the next release of the DLLs.

A range error for the exponent was not being trapped. The new IOSTAT value is 452 and the corresponding message is 'Exponent out of range on read'.