XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) (12/04/89)
Hallo,
the fortran example in my previous message is wrong. It has to be:
program test
numatm=-1
write(*,4177)
4711 format('No comes the bug',i4)
1 numatm
end
Sorry for wasting the network.
Regards
Martin Knoblauch
TH-Darmstadt
Physical Chemistry 1
Petersenstrasse 20
D-6100 Darmstadt, FRG
BITNET: <XBR2D96D@DDATHD21>
PS: This is for Phil: K&R state that blank, tab, nl and comments are treated
collectively as "white space" character. (K&R 1978, p.179)fsfacca@LERC08.LERC.NASA.GOV (Tony Facca) (12/05/89)
Knobi der Rechnerschrat <XBR2D96D%DDATHD21.BITNET@cunyvm.cuny.edu> writes: > I discovered the following two bugs in the C and f77 compiler of 3.2. I know >I should report them directly to Calvin Vu, but I've lost his e-mail address. > > First I have the following Fortran Code: > > program test > numatm = -1 > write(*,4711) >4711 format('Next comes the bug',i4) > 1 numatm > end [ I did some editing, but the idea has been preserved ] > > The program compiles fine, but tell me where does is put the continuation >line? To the format statement? That's nonsense? To the write statement? That >would be the meaning, but to late and it doesn't. > The continuation line is just that: a continuation of the FORMAT statement. So, the 4th line of the program is: 4711 format ('Next comes the bug', i4) numatm That much is obvious, right? So, why doesn't the compiler complain? According to the ANSI X3.9-1978 (FORTRAN 77), Section 13.1.2 says: "Character data may follow the right parenthesis that ends the format specification, with no effect on the format specification." Looks like this piece of code conforms to the standard quite nicely. The point about it being nonsense is still debatable. But at least its FORTRAN 77 STANDARD nonsense! :-) Tony Facca & Dan Whipple -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------
phil@BRL.MIL (Phil Dykstra) (12/05/89)
> K&R state that blank, tab, nl and comments are treated > collectively as "white space" character. (K&R 1978, p.179) Sure enough, I just looked and both the original and 2nd edition state this. However, the early Unix C compilers (and even most current ones) would replace comments by nothing at all rather than by a space [to be precise, the C preprocessor would do this]. This behavior was/is often exploited for token concatenation. ANSI adopted the original spec that comment = whitespace and thus provided the new '##' operator for concatenation. Note that one of the actions of the GNU C compiler "-traditional" flag is to: * In the preprocessor, comments convert to nothing at all, rather than to a space. This allows traditional token concatenation. So, SGI is just following the convention that most UNIX C compilers do. Strict ANSI compilers however will not do this. - Phil
sysjohn@physics.utoronto.ca (John Chee Wah) (03/17/90)
Here is a piece of code (isn't mines) that I think should work. Loops and
goto ends with a single continue statement. The program will work if the
two loops have separate statement labels.
System is 4D/240 with 3.2.1.
-----
write(6,'(''Enter integer 0 or less and program will loop: '',$)')
read(5,*)iup
c
do 1 i=-1,1
if(i.gt.iup)goto 1
do 1 j=-1,1
write(6,'(''j='',i4)')j
1 continue
c
stop
endW0L@psuvm.psu.edu (Bill Lasher) (03/17/90)
I believe you are violating the rule that says you can't go to a statement within a DO loop except from the top. I tried the program on our mainframe (IBM) using two different compilers. The IBM FORTRAN 77 compiler accepted the statements, but the WATFIV compiler did not. I'm not sure what the standard reads, but I recommend separating the loops. That way there is no question.
bron@bronze.wpd.sgi.com (Bron Campbell Nelson) (03/18/90)
In article <1990Mar17.021042.20480@helios.physics.utoronto.ca>, sysjohn@physics.utoronto.ca (John Chee Wah) writes: > > Here is a piece of code (isn't mines) that I think should work. Loops and > goto ends with a single continue statement. The program will work if the > two loops have separate statement labels. > System is 4D/240 with 3.2.1. > ----- > write(6,'(''Enter integer 0 or less and program will loop: '',$)') > read(5,*)iup > c > do 1 i=-1,1 > if(i.gt.iup)goto 1 > do 1 j=-1,1 > write(6,'(''j='',i4)')j > 1 continue > c > stop > end This question comes up over and over in different ways. This is not really a bug in the Fortran compiler; the code as written is not standard conforming, and its exact meaning is ambiguous. I admit that I think the compiler ought to give an error message, but it does not (and neither do most other Fortran compilers). The problem is that statement 1 is considered to be a statement in the inner loop. When you branch to it, you have branched from an outer block into an inner block, which is not allowed (just as branching directly to the "write" statement is not allowed). The Fortran compiler gets confused about whether it should "continue" back at the j loop, or the i loop. In fact it goes to the inner (j) loop which has not been properly initialized, picks up garbage off the stack, and goes. This topic gets hashed out in comp.lang.fortran every year or so. Many other Fortran compilers have similar behavior, some do it differently, some give a compile error. Using separate labels for the loops is the right thing to do. -- Bron Campbell Nelson bron@sgi.com or possibly ..!ames!sgi!bron These statements are my own, not those of Silicon Graphics.
sysjohn@physics.utoronto.ca (John Chee Wah) (03/18/90)
In article <53943@sgi.sgi.com> bron@bronze.wpd.sgi.com (Bron Campbell Nelson) writes: >In article <1990Mar17.021042.20480@helios.physics.utoronto.ca>, sysjohn@physics.utoronto.ca (John Chee Wah) writes: >> >> Here is a piece of code (isn't mines) that I think should work. Loops and >> goto ends with a single continue statement. The program will work if the >> two loops have separate statement labels. >> System is 4D/240 with 3.2.1. >> ----- >> write(6,'(''Enter integer 0 or less and program will loop: '',$)') >> read(5,*)iup >> c >> do 1 i=-1,1 >> if(i.gt.iup)goto 1 >> do 1 j=-1,1 >> write(6,'(''j='',i4)')j >> 1 continue >> c >> stop >> end > >This question comes up over and over in different ways. This is not >really a bug in the Fortran compiler; the code as written is not standard >conforming, and its exact meaning is ambiguous. I admit that I think the >compiler ought to give an error message, but it does not (and neither >do most other Fortran compilers). > >The problem is that statement 1 is considered to be a statement in the >inner loop. When you branch to it, you have branched from an outer >block into an inner block, which is not allowed (just as branching directly >to the "write" statement is not allowed). The Fortran compiler >gets confused about whether it should "continue" back at the j loop, or >the i loop. In fact it goes to the inner (j) loop which has not been >properly initialized, picks up garbage off the stack, and goes. > >This topic gets hashed out in comp.lang.fortran every year or so. Many >other Fortran compilers have similar behavior, some do it differently, >some give a compile error. Using separate labels for the loops is the >right thing to do. Definitely placing other statement labels should things clear to others and compiler. The problem is that the code is similar to part of a large program that ran on VAX/VMS and on SUN (I think) and it is just that when users (who just wants to run the programs) tries to compile and run the program on the iris, don't understand why it does not work. You get answers like "but it works on the VAX!" Maybe ambiguous things like this, could be documented in the Fortran manual. > > >-- >Bron Campbell Nelson >bron@sgi.com or possibly ..!ames!sgi!bron >These statements are my own, not those of Silicon Graphics.