Silverfrost Forums

Welcome to our forums

FORMAT mismatch: F-Format with UNKNOWN item

12 Mar 2022 2:03 #28825

The following program has format specifiers that are mismatched to the variables in the I/O list. FTN95 catches the errors, but the wording of the error message is a bit puzzling.

program mismatch
implicit none
integer i
real r
character(2) :: iline = '1.', jline='123'
read(iline,'(F2.1)')i !reading real number into integer variable using F format
print '(ES10.3,4x,I10)',i,i !printing integer using ES format
read(jline,'(I3)')r  !reading integer data into real variable using I format
print '(ES10.3,4x,I10)',r,r !printing real using I format
end program

The error message is:

FORMAT mismatch: F-Format with UNKNOWN item (at data position 1). at address 1a0093c9

Surely, the compiler knows the type of the variable as well as its name (if /debug is specified)? Running the same program with Gfortran gives

At line 6 of file mm.f90
Fortran runtime error: Expected REAL for item 1 in formatted transfer, got INTEGER
(F2.1)
 ^
12 Mar 2022 4:19 #28827

mecej4

Thanks for the feedback. I will take a look at this.

13 Mar 2022 8:08 #28828

When I ran the test program in 32 bit mode, I got a compilation warning as jline is CHARACTER*(2) and the data supplied is 3 chars long. This had a line number. Sure, there's not a line number with the runtime error, but 'format/data mismatch' is a hint as what to look for if not where to look.

Error messages aren't always diagnostic of where the problem lies in source code (or what it really is), unfortunately, certainly not at run time.

I'm presuming that the error message reported was a /debug message, because I didn't get it with a straightforward compile and run.

Eddie

13 Mar 2022 12:41 #28829

Eddie, there are many thing wrong with the program; it was intended to demonstrate the unexpected 'UNKNOWN item' error message. As usual, the first run time error to be encountered causes the program to abort, so there can be any number of remaining errors that need fixing beyond the error that caused the abort.

You can change the character variable length from 2 to 3 in the fifth line of the program if you wish to remove the warning.

14 Mar 2022 7:30 #28830

Mecej4, The point was that I didn't get the same message as you and I wondered why.

E

14 Mar 2022 8:44 #28831

I also recently got an 'UNKNOWN item' error report, which turned out to be an out of bounds subscript for an integer array. This 'UNKNOWN item' error report was a bit confusing at first, but found a logic error where a zero subscript was not identified.

14 Mar 2022 12:26 #28832

The 'UNKNOWN item' runtime I/O error is shown for certain combinations of errors. The following version of the test program displays this behaviour:

program mismatch
implicit none
integer i
real r
character(2) :: iline = '1.', jline='12'
read(iline,'(F2.1)')i !reading real number into integer variable using F format
print '(ES10.3,4x,I10)',i,i !printing integer using ES format
read(jline,'(I3)')r  !reading integer data into real variable using I format
print '(ES10.3,4x,I10)',r,r !printing real using I format
end program

The expected output is something similar to what the NAG compiler gave:

Test-1

 ios =  135  for  READ 1, msg: Invalid edit descriptor for integer i/o-list item
 ios =  135  for WRITE 1, msg: Invalid edit descriptor for integer i/o-list item

Test-2

 ios =  134  for  READ 2, msg: Invalid edit descriptor for real i/o-list item
 ios =  134  for WRITE 2, msg: Invalid edit descriptor for real i/o-list item

FTN95 8.83, with or without /64 and with or without /debug gives:

Test-1

 ios =           51 for  READ 1, msg: FORMAT mismatch: F-Format with UNKNOWN item (at data position 1).
 ios =           51 for WRITE 1, msg: FORMAT mismatch: ES-Format with INTEGER item (at data position 1).

Test-2

 ios =           51 for WRITE 2, msg: FORMAT mismatch: I-Format with REAL item (at data position 2).

It may be noted that FTN95 does not detect the second READ error (reading data into a real variable using an I3 format).

21 Mar 2022 7:21 #28837

This has now been corrected for the next release of the DLLs.

Please login to reply.