wierd f77 bug -- Fortran blanks not THAT bad!

[hopp at nbs-amrf.UUCP]

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 at udel-relay
Metrology A127		      BELL: (301)921-2461
Washington, DC 20234