C language lawyers... help! - (nf)
ericf at inmet.UUCP
ericf at inmet.UUCP
Wed Jul 18 22:50:29 AEST 1984
#N:inmet:5000020:000:1744
inmet!ericf Jul 17 10:14:00 1984
OK you C language lawyers out there, here's one for you.
Very wierd things happend in the 2.9BSD compiler with the following program
(which is not designed to do anything interesting, other than demonstrate
the problem):
main(argc, argv)
int argc;
char *argv[];
{
int foo;
long val;
#ifdef BUG
for (foo = 1 ; foo < 10 ; foo++) {
#endif
val = grimble(foo);
printf("%D ", val);
#ifdef BUG
}
#endif
}
long grimble(arg)
{
return((long) arg);
}
On the 2.9BSD C compiler (whichever one THAT is... I can never keep track),
if this is compiled using "cc cbug.c", I get "22: grimble redeclared". Fine.
That's about what I'd expect. If I do "cc -DBUG cbug.c" I get NO error. When
I run the resulting a.out file, I get all zeros. But wait, it gets worse.
Under the 4.1BSD C compiler, I get no errors regardless of whether BUG
is defined or not, and get reasonable results when I run the thing.
Now, I can see how maybe the 2.9 behavior makes sense, in that grimble in
implicitly declared within the scope of the compound statement (in the -DBUG
case), and so is not declared when the compiler sees the definition of
grimble later on. However, the 4.1 compiler doesn't seem to care, and I
don't think the old PWB compiler does either.
My question is... what SHOULD the behavior of the compiler be in this
situation. I.e., is it a bug, a feature, or is this going to trigger
billions and billions of arguments with a strong religious ferver?
If this has been discussed before, forgive me (Please?). Respond
by MAIL ONLY, and if you're interested in the results, send me mail,
and I'll reply (or post if there's demand).
Thanks!
-Eric Feigenson
Intermetrics, Inc.
{harpo, ima, ihnp4}!inmet!ericf
More information about the Comp.lang.c
mailing list