The problem is that the I/O system reads one (admittedly malformed) field into two variables in list directed input. Take this one line and put it in a file named 'the_test_file' --------- cut --------- cut --------- cut --------- cut 13.5-1420.83 1 0.350E+00 -0.181E+19 --------- cut --------- cut --------- cut --------- cut In the same directory, save the following code, compile and run... --------- cut --------- cut --------- cut --------- cut program showbug real*4 press,atemp,zalt,junk,therest integer readstat open (10, file='the_test_file',status='old') read(10,*,end=223,err=555,iostat=readstat) & zalt,atemp,junk,press, therest 223 continue 555 if (readstat.gt.0) then print *,'Error!' stop endif print *,'No Error' print *,'zalt=',zalt,',atemp=',atemp,',junk=',junk print *,'press=',press,',therest=',therest end --------- cut --------- cut --------- cut --------- cut I used g77 -o showbug showbug.f When I ran this I got the following output. --------- cut --------- cut --------- cut --------- cut % ./showbug No Error zalt= 0.,atemp= 0.829999983,junk= 1. press= 0.349999994,therest= -1.80999996E+18 --------- cut --------- cut --------- cut --------- cut The problem is that the I/O library reads that first string of characters into *two* fields. Notice the value of 'atemp'. It's 0.83, the last bit of that first malformed field. It is impossible in my testing to make this line throw an I/O error. I understand that the first field in my test case is malformed, that it's really two numbers run together. What I'd hoped for was for the i/o subsystem to throw an error so that I would be able to catch it in my processing software. But since g77 doesn't see this field as malformed, I can't. This is at odds with the f77 standard, in my opinion (and also the opinion of Van Snyder here at JPL) According to the F77 standard at http://www.fortran.com/fortran/F77_std/rjcnf0001-sh-13.html#sh-13.6 legitimate value separators are 1. A comma optionally preceded by one or more contiguous blanks and optionally followed by one or more contiguous blanks 2. A slash optionally preceded by one or more contiguous blanks and optionally followed by one or more contiguous blanks 3. One or more contiguous blanks between two constants or following the last constant My reading of that says that at the very least it should not have read that one field into two values. The particulars of my system are... % g77 -v Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-8) % uname -a Linux iguana.jpl.nasa.gov 2.6.9-55.0.2.plus.c4smp #1 SMP Fri Jul 6 05:25:07 EDT 2007 i686 i686 i386 GNU/Linux William Daffer
I tried you example with g77 and it shows "No Error". However, using all other compilers I have (ifort, sunf95, openf95, g95, gfortran, NAG f95) it shows "Error!". ... Ok, after re-reading your bug report, I see that you report a bug against g77 and not against gfortran (which is not affected). g77 was part of GCC 3.4.x and is no longer supported. gfortran is part of GCC since 4.0.0, supports Fortran 90/95 (and thus also FORTRAN 77); it also supports Cray pointers and other legacy extensions and it should support 99% of the extensions of g77. Plus it has better diagnostic capabilities. You should be able to get gfortran binaries (please use gfortran 4.1.x or later) from your vendor (RedHat) or from: http://gcc.gnu.org/wiki/GFortranBinaries#GNU/Linux Closed as WONTFIX (with regards to g77), I could have also used WORKSFORME as gfortran behaves properly. Please use the fortran<At>gcc.gnu.org mailing list if you have further questions.
Subject: Re: f77 reads one field into two variables in list directed i/o On Thu, 2007-08-30 at 18:26 +0000, burnus at gcc dot gnu dot org wrote: > > ------- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 18:26 ------- > I tried you example with g77 and it shows "No Error". However, using all other > compilers I have (ifort, sunf95, openf95, g95, gfortran, NAG f95) it shows > "Error!". Yes, that's what happened when we tried lahey and nag. > > ... > > Ok, after re-reading your bug report, I see that you report a bug against g77 > and not against gfortran (which is not affected). > > g77 was part of GCC 3.4.x and is no longer supported. > Okay. > gfortran is part of GCC since 4.0.0, supports Fortran 90/95 (and thus also > FORTRAN 77); it also supports Cray pointers and other legacy extensions and it > should support 99% of the extensions of g77. Plus it has better diagnostic > capabilities. Okay. I'll see whether we can use that. thanks for the quick response! William > > You should be able to get gfortran binaries (please use gfortran 4.1.x or > later) from your vendor (RedHat) or from: > http://gcc.gnu.org/wiki/GFortranBinaries#GNU/Linux > > Closed as WONTFIX (with regards to g77), I could have also used WORKSFORME as > gfortran behaves properly. > > Please use the fortran<At>gcc.gnu.org mailing list if you have further > questions. > >