strange effects with enumerated types
Chris Torek
chris at mimsy.UUCP
Thu Oct 20 01:00:34 AEST 1988
In article <20 at auspex.UUCP> guy at auspex.UUCP (Guy Harris) writes:
>... From that, I infer that the declaration "a", "b",and "c" in the
>definition of "new_struct" should be suspended inside the block
>constituting "test_fn1", so that this is a compiler bug.
It is quite definitely a compiler bug. Anything that causes a, b, and
c to have the values 2, 3, and 4 when the most recent `enum'
declaration read `enum { a=1, b, c }' is clearly a bug! I even know
just where, but not precisely what to do to fix it. In mip/pftn.c we
find the routine `defid', which, for a `MOE' (Member Of Enum) type, has
the following code:
if( scl == class ){
if( p->offset!= strucoff++ ) break;
psave( idp );
}
break;
What happens is that `strucoff' (which keeps track of the offset of
members of structures---enum type declarations are fudged as structures
inside pcc) is incremented *twice*, once here (where it checks for
a mismatch and may or may not allow the redeclaration, depending on
whether this hides a previous declaration) and once below. I *think*
that it should return after calling psave(), except that I am not sure
that, if p->offset != strucoff++, strucoff should have been incremented.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris at mimsy.umd.edu Path: uunet!mimsy!chris
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list