marcel@nluug.nl (Marcel Bernards) (06/20/89)
Hello SUN managers,
We got still trouble with FORTRAN 1.1 with the 6 patches applied.
it is a internal read problem with blank chars.
It causes to hang up the processor for tty input thats never coming
(except for ^C ;-( )
Perfmeter is on 100% CPU consumption.
Machine : SUN 3/50
OS : SUNOS 4.0
Language : SUN FORTRAN 1.1 With patches applied in libs
#include blanks.f
----------------INCLUDE-------------
program blanks
c
c--- test internal read ( string to number )
c--- if only blanks in string then processor is waiting !!!!!
c--- YECH!
c
character string*10
integer number
c
c--- read string from stdin keyboard
c
10 PRINT *,' Type sting between quotes'
READ *,string
c
c--- read a string into an integer
c
READ( string,*,ERR=999 ) number
PRINT *,' NUMBER : ',number
goto 10
c
c--- here print the string if conversion failes
c
999 PRINT *,' STRING : ',string
goto 10
c
c---
c
end
--------- END of INCLUDE --------
Anyone has an idea if this one is a bug or a feature ??
one of our programmers encountered this one!!
Greetings
Marcel Bernards, UNIX & Net sysadm Netherlands Energy Research Foundation ECN
P.O. Box 1, 1755 ZG Petten, PHONE: 09 312246 4342 EARN/BITNET:ESU0130@HPEENR51
EMAIL: marcel%ecn@{nluug.nl,uunet.uu.net},marcel@ecn.uucp ..!hp4nl!ecn!marcel
SCREAMNet : AAAAAARGHH!HUH?? : Disclaimer: "The AntiChrist is the Computer !" ji@walkuere.altair.fr (John Ioannidis) (06/21/89)
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 <number> 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 <appropriate disclaimers> In-Real-Life: John Ioannidis E-Mail-To: <ji@cs.columbia.edu> (preferred), or <ji@walkuere.altair.fr> 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
ji@walkuere.altair.fr (John Ioannidis) (06/21/89)
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 <number> 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 <appropriate disclaimers> In-Real-Life: John Ioannidis E-Mail-To: <ji@cs.columbia.edu> (preferred), or <ji@walkuere.altair.fr> 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
maine@altair.dfrf.nasa.gov (Richard Maine) (06/22/89)
In article <3983@kalliope.rice.edu> ecn!marcel@nluug.nl (Marcel Bernards) writes: > We got still trouble with FORTRAN 1.1 with the 6 patches applied. > it is a internal read problem with blank chars. > It causes to hang up the processor for tty input thats never coming > .... > READ( string,*,ERR=999 ) number > .... > Anyone has an idea if this one is a bug or a feature ?? > one of our programmers encountered this one!! The above line is "illegal" (non-ANSI) FORTRAN. ANSI does not allow list directed internal reads. Thus the program is buggy. Of course, its a plausible enough extension to want. This particular sample is easy to recode per ANSI, but it can get annoying for more complicated cases. Still, it can be done and is worth the bother if you care at all about portability - or perhaps even if you don't. Although I wish this were standard, I suspect that a major reason that it isn't in the standard is that it poses several complications that ANSI didn't want to deal with. When you use extensions like this, you always take the risk that the vendor just ignored the complications, which is what this looks like to me. Having said the above, let me hasten to add that there is no "acceptable" (to me) justification for the compiler to act like it appears to, regardless of whether the code is legal or not. If the compiler does not intend to support list directed internal reads as an ANSI extension, then it should give a compilation error. If it does intend to support them, then it should deal with complications like this. Either way, it's a compiler bug in my book. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.1.1] (Outside mail won't get to altair.dfrf.nasa.gov, so don't bother trying).