🚀 go-pugleaf

In article <20@auspex.UUCP> guy@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@mimsy.umd.edu	Path:	uunet!mimsy!chris