Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!husc6!rice!sun-spots-request From: ji@walkuere.altair.fr (John Ioannidis) Newsgroups: comp.sys.sun Subject: FORTRAN 1.1 SUNOS 4.0 with 6 patches still buggy ! Keywords: SunOS Message-ID: <4091@kalliope.rice.edu> Date: 21 Jun 89 10:47:12 GMT Sender: usenet@rice.edu Organization: Sun-Spots Lines: 39 Approved: Sun-Spots@rice.edu X-Sun-Spots-Digest: Volume 8, Issue 48, message 4 of 19 The line READ( string,*,ERR=999 ) number isn't entirely kosher f77, of course, but that's OK, so long as your compiler accepts it. THe problem lies in the fact that an all-blank string should be generating an EOF and a non-numeric string should be generating an ERR condition, and that's not handled properly To get some more information, I added the clause END=998 and run your program first on a Pyramid in the bsd universe and then on a Unisys 7000/40 running 4.3Tahoe. On the Tahoe, it behaved the way I expected it to; an all-blanks string gave it an EOF (and it branched to label 998), and a non-numeric string (like 'foo') gave it an ERR. On the Pyramid, the results were the same as you describe, that is, if you give it an all-blanks string, it loops, guzzling down CPU cycles. I ^Zed it, ran gcore and dbx, and it showed that it was looping in an exit() procedure. Apparently, EOF is not handled properly. Also, if you give it a non-numeric string, it reads 0 into instead of generating an error. I don't have a Sun f77 compiler to test it with (we don't need no stinking fortran here :^) ) FYI, there were four-five articles in Sun-spots about a month ago on EOF problems with the fortran compiler. You might want to get them from the archives and check them out. Hope this helps, /ji #include In-Real-Life: John Ioannidis E-Mail-To: (preferred), or P-Mail-To: GIP-Altair, Dom de Voluceau BP105, Rocquencourt 78153 Le Chesnay, FR V-Mail-To: +33 1 39635227, +33 1 39635417 ... It's all greek to me