mark@cci632.UUCP (Mark Stevans) (07/29/87)
If you attempt to declare a function argument that is not present in the
argument list, like in the following program:
main()
{
bar(3);
}
bar(contect)
int context;
{
}
the C compilers will give an error message about "declared argument context"
not found. However, the following program:
int context;
main()
{
bar(3);
}
bar(contect)
int context;
{
}
passes both "cc" and "lint" on both System V and 4.2bsd without giving any
messages to inform you that you misspelled "context" as "contect". The
compiler seems to think that there are two arguments: context and contect.
Lint will tell you that you are hiding your global, and that the two arguments
of bar, context and contect, are unused.
I believe this is a bug. In fact, the above situation was actually
encountered by a colleague, so this is not a purely theoretical issue.
Mark "Bugsy" Stevans
cci632!markguy%gorodish@Sun.COM (Guy Harris) (07/30/87)
> I believe this is a bug.
Yes, this is a bug. There is a fix to "pftn.c" that will, at least,
make the compiler complain that "declared argument context is
missing". I think I posted the fix to comp.bugs.sys5 and/or
comp.bugs.4bsd a while ago; you might try digging through your
archives for that. If it doesn't turn up, I'll repost it.
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.comwsinpdb@lso.win.tue.nl (Paul de Bra) (04/10/90)
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! "mf4.c", line 1362: illegal character: 043 (octal) "mf4.c", line 1362: cannot recover from earlier errors: goodbye! The commands for compiling each file look like: cc -O -I.. -c mf2.c I compiled the stuff with gcc without getting any errors. Also, when I say cc -P -I.. mf2.c; cc -O -I.. -c mf2.i I get no errors, so just by splitting the compilation in 2 supposedly equivalent parts the errors go away. Has anyone seen this before? (Please don't tell me I should use gcc instead. I want to try the X11 stuff and the gnu utils, using gas and gnu-ld, don't like the shared libraries.) Paul. (debra@research.att.com)
scjones@sdrc.UUCP (Larry Jones) (04/12/90)
In article <1064@tuewsd.lso.win.tue.nl>, wsinpdb@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! > > I compiled the stuff with gcc without getting any errors. > Also, when I say > > cc -P -I.. mf2.c; cc -O -I.. -c mf2.i > > I get no errors, so just by splitting the compilation in 2 supposedly > equivalent parts the errors go away. Well, 043 is '#', so it would seem that you have some preprocessor directives that aren't getting interpreted by the preprocessor but are instead making their way into the compiler which is choking on them. 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 (the net result of your double cc), I would guess that there is a comment before the '#' which gets removed by the first cpp so that the '#' is in column 1 for the second pass. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@SDRC.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 "You know how Einstein got bad grades as a kid? Well MINE are even WORSE!" -Calvin
wsinpdb@lso.win.tue.nl (Paul de Bra) (04/12/90)
In article <1282@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes: >In article <1064@tuewsd.lso.win.tue.nl>, wsinpdb@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@research.att.com)
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/13/90)
In article <1064@tuewsd.lso.win.tue.nl> wsinpdb@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! Since 043 is a '#' character, I suspect the source code is attempting to use the ANSI-C stringizing or pasting features, which generally aren't supported by older compilers. Look on line 1811 of mf2.c and see how it's trying to use the '#' character..