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