hopp@nbs-amrf.UUCP (05/10/84)
Guy Harris (rlgvax!guy) writes in net.lang: >While we're on the subject of Fortran and lexical analysis, here's the worst >consequence of the "blanks are ignored" rule I've seen yet, which appeared >recently in net.unix-wizards: > >> We are running USG 5.0 on a VAX 11/780. Here is part of a subroutine >> from an f77 program that compiles properly: >> >> subroutine scale (buff2,f2,ctscl2,type2) >> character buff2*132,cont2*2,type2*4 >> integer a2,d,e2,f2,ctscl2 >> cont2 = ' ' >> a2 = index (buff2,'scale') >> if (a2 .ne. 0) then >> do 100 d = a2+5,len(buff2) >> if (f2 .eq. 1) goto 200 >> if ((buff2(d,d) .eq. ' ') .or.(buff2(d,d) .eq. ' ')) >> & go to 100 >> e2=d >> f2=1 >> go to 100 >> 200 if ((buff2(d,d) .ne. ' ') .or. (buff2(d,d) .ne. ' ')) >> & go to 100 >> c i = strtok (ctscl2,buff2,cont2,'i') >> 100 continue >> endif >> >> If, however, you change the name of the variable 'd' to 'd2' throughout, >> the compiler flags a syntax error on the 'do 100 ...' statement. >> >> Any guesses? >> >> Newsgroups: net.unix-wizards,net.bugs.usg,net.lang.f77 >> Subject: weird f77 bug solved.... >> >> The reason for this is the f77 extension which allows a double >> precision exponent, which is a multiplier base 10. In other words, >> '1d2' equates to '100' (1 * 10^2). f77, on the statement above, >> was squeezing out the space between the '100' and the 'd2' and >> parsing it as a double precision constant '100d2'; thus the >> syntax error. > >How'd ya like that one, folks? A program that, by all rights, *should* >be perfectly legal is made illegal by an unfortunate (but otherwise legal!) >choice of variable name. ("e2" would have been just as bad, for the same >reason.) Come on. That's a compiler bug. We're running 4.1 under Eunice on an 11/780 and there's no problem at all. We can even compile the program under VMS (after changing substring references to "d:d" from "d,d") and nobody complains. If f77 under USG 5.0 complains, someone should complain about the compiler, not about Fortran. The language is unambiguous, there is a correct parse, and most compilers aren't so brain damaged that they can't interpret "do100d=1,2" OR "do100d2=1,2". It looks like that was one the implementers just missed. The only complaint I have about Fortran and blanks is that it DOESN'T ignore blanks at the start of a line. (Or rather, that it insists on having them there.) Can't someone on the ANSI committee show some true grit and demand comment delimiters instead of comment lines?! After all, almost everyone can get an exclamation mark into a text file, and that would do nicely. Then we could do something about continuation lines.... Three cheers for state machine languages! Fie on upward compatibility! -- Ted Hopp UUCP: {seismo,allegra}!umcp-cs!nbs-amrf!hopp National Bureau of Standards ARPA: hopp.nbs-amrf.umcp-cs@udel-relay Metrology A127 BELL: (301)921-2461 Washington, DC 20234
jlg@lanl-a.UUCP (05/12/84)
iiiiii The ANSI committee HAS bit the bullet and gone to free format lines (although, I'm still not sure about the significance of blanks within lines). In Fortran 8X, lines can start anywhere and comments begin with '!' anywhere on the line. Some Fortran 77 compilers already recognize the '!' for comments.