strange compiler bug

[Paul de Bra]

In article <1282 at sdrc.UUCP> scjones at sdrc.UUCP (Larry Jones) writes:
>In article <1064 at tuewsd.lso.win.tue.nl>, wsinpdb at lso.win.tue.nl (Paul de Bra) writes:
>> When compiling metafont on a 386, using the AT&T (development system 4.1.6)
>> c-compiler, I get bogus errors like this:
>> 
>> "mf2.c", line 1811: illegal character: 043 (octal)
>> "mf2.c", line 1811: cannot recover from earlier errors: goodbye!
> [ stuff deleted ]1
>... The place that I've seen this most
>often is when the '#' isn't in column 1.  Since the problem goes
>away when you run the file through the preprocessor twice...

Many people sent their comments (thanks folks), but nobody got it right
unfortunately. The source code had no comments, no # signs or anything
in the vincinity of the reported error. (The code is, as the name suggests,
the source for metafont (2.0), generated by web2c)

So I dug in a little deeper and this is what happened (I trimmed down the file):

The following source lines (18 to 21 in the file):
  if ( ! ( abs ( mem [ curedges + 2 ] .hhfield .lhfield + mem [ curedges + 3 ]
  .hhfield .lhfield - 8192 ) < 4096 ) || ! ( abs ( mem [ curedges + 2 ]
  .hhfield .v.RH + mem [ curedges + 3 ] .hhfield .lhfield - 8192 ) < 4096 ) )
  fixoffset () ;

are translated by the preprocessor to: (output from cc -E)
  if ( ! ( zabs((integer) ( mem [ curedges + 2 ] .hhfield .v.LH + mem [ curedges + 3 ]    .hhfield .v.LH - 8192 )) < 4096 ) || ! ( # 20 "mf2.c"
zabs((integer) ( mem [ curedges + 2 ]    .hhfield .v.RH + mem [ curedges + 3 ] .hhfield .v.LH - 8192 )) < 4096 ) )
# 21 "mf2.c"

Note that the required newline before the # 20 "mf2.c" is missing.
This is clearly a preprocessor bug.

The problem went away by performing cc -P first as it rearranges the
expression in a similar fashion but does not generate new
preprocessor commands, like the ones to remember source line numbers.

Now, since the piece of source code that triggered the preprocessor bug
is the source for Metafont, I wonder: who else has encountered this bug
when compiling metafont 2.0?

Paul.
(debra at research.att.com)