Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.bugs.4bsd
Subject: Re: strange effects with enumerated types
Keywords: enum,courier
Message-ID: <14065@mimsy.UUCP>
Date: 19 Oct 88 15:00:34 GMT
References: <142@csaran.cs.tcd.ie> <20@auspex.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 27

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