Sorry for bothering you but my students really do a stress test on Fortran (and on me as well ). Some of their inventions, however, make me wonder if things are going as they should be.
program czy
implicit none
real :: o
integer :: ios
write(*, '(A)', advance ='no') "give number: "
read(*, '(A)', iostat = ios) o
if (ios /= 0) stop 'read error'
print *, o
end program czy
Despite an obvious incompatibility between the format descriptor and the I/O list in read statement, not only ifx and gfortran both compile the code w/o any warnings, no matter what options I give (-Wall, -pedantic, -fcheck=all to gfortran) but also there is no trace of any error at run time.
$ gfortran -Wall -pedantic -Fcheck=all r.f90 && ./a.out
give number: 123456789
1.66889336E-07
$ ./a.out
give number: asdfghjkl
2.69706981E+23
I have to admit that I am a bit confused. Is this the expected behavior?
Edit: I tried to change the descriptor to an explicit length, read (*, '(A10)',...
Nothing has changed.
Some time ago, I tried to download and install g95 but it did not work on my Linux (rather modern) machines. Any pointer to a working version would be appreciated.
According to this document, the following are processor dependent:
[…]
• the set of error conditions that can occur in input/output statements (12.11.1);
• when an input/output error condition occurs or is detected (12.11.1);
You, and they, are at the mercy of the quality of implementation of the compiler. Never too early to learn that lesson.
Asking DeepSeek if there is anything wrong with the posted code gives
Yes, there is an issue with the Fortran code you provided. The problem lies in the read statement. Specifically, you are using the '(A)' format specifier, which is for reading character data, but you are trying to read into a real variable o . This mismatch between the format specifier and the variable type will cause a runtime error.
and a corrected code
program czy
implicit none
real :: o
integer :: ios
write(*, '(A)', advance='no') "give number: "
read(*, *, iostat=ios) o ! Use list-directed input for real numbers
if (ios /= 0) stop 'read error'
print *, o
end program czy
One could suggest that students use LLMs to understand bugs that have not been caught by compilers, but they may use LLMs to do all the work.
program czy
use iso_fortran_env, only: wp => real32
implicit none
real(wp) :: o
integer :: ios
o = 0.0_wp
write(*, '(A)', advance ='no') "give number: "
read(*, *, iostat = ios) o
if (ios /= 0) stop 'read error'
print *, o
end program czy
works better since the input from the CLI anyway is the first column. After compilation (gfortran 14.2) to yield executable ping:
$ ./ping
give number: 123
123.000000
$ ./ping
give number: abc
STOP read error
Similar code was legal in Fortran 66 - as Hollerith data could be (but not recommended to be) stored in data of type REAL. Hollerith constants were removed from Fortran 77, when CHARACTER data type was added. But most compilers still support ancient code.
There was a runtime error, the variable o had the wrong value, but it was not detected by the processor. I think the reason for this is that fortran programs have a long history, going back even before f77, of type punning. Particularly, character variables in the pre-f77 days were stored in integer (sometimes real, complex, double precision, or logical) variables and arrays, and they were processed exactly as this test program shows, the integer array was read and written with an A format. The character data type was added in f77, but most compilers still allowed the type punninng for legacy reasons. Here we are 50+ years later and the practice is still allowed by default on some compilers.
I tried Silverfrost FTN95, which has good diagnostics.
It did not report an error.
Is “read (*, ‘(A)’, iostat = ios) o” an error ?
Or is it support for FORTRAN storage of 4-character strings in Integer or real variables ?
program czy
implicit none
real :: o
integer :: ios
write(*, '(A)', advance ='no') "give number: "
read(*, '(A)', iostat = ios) o
if (ios /= 0) stop 'read error'
print *, o, ios
write (*,'(A)') o
end program czy
Indeed, it outputs ‘1234’. I have checked gfortran docs and found the possibility to convert Hollerith constants to REAL (x = 4Habcd) and even CHARACTER to REAL (x = 'abcd'). Both, however, are reported as Extensions and the latter requires -fdec-char-conversions to be accepted. I could not find any info on real values I/O using 'A' descriptor which seems to be complementary to those extensions.
Still I would expect that if the conversions on assignment are reported as extensions, the I/O conversions would be reported as well. And rejected with ‘-std=f2018’ option (as is rejected a Hollerith constant)
F2018 Draft states:
13.7.4 Character editing
1 The A[w] edit descriptor is used with an input/output list item of type character.
You have to look in the Fortran 66 Standard, and Appendix A2(3) in the Fortran 77 Standard.
Reading Hollerith data into, and writing from, numeric variables via the A edit descriptor was a fact of life before Fortran 77. When F77 came out, those 20 years of existing Fortran programs didn’t suddenly disappear. So compilers have historically been lax about checking FORMATs for this. Whether it is still justified almost 50 years later is a matter of debate. (At this point I’d like to see it diagnosed. But it isn’t an easy check to fully implement.)
-rw-rw-r-- 1 john 1357116 Feb 6 2021 g95_source.tgz
-rw-rw-r-- 1 john 3396712 Feb 15 2021 g95-x86_64-32-linux.tgz
-rw-rw-r-- 1 john 3395979 Feb 6 2021 g95-x86_64-64-linux.tgz
and could email them. I don’t now remember what I did 4 years ago to install g95 but it works for me. The one with 64-32 in its title uses 32 bits for default integers, and I prefer it. There are of course unfixed bugs. One that I discovered recently is that exponent(Inf) should be huge(0) if Inf is of any real kind.
). Some of their inventions, however, make me wonder if things are going as they should be.