From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Tue, 11 Jun 96 17:47:34 PDT
Subject: Re: Minor bug
Message-Id: <CMM.0.90.4.834540454.cwilson@Xenon.Stanford.EDU>

> Hi,
> 	This is regarding snoot. Currently, declarations of the form:
> 		'int * const const volatile', 
> do not give an error as they should. The reason for this is that in the
> function 'dclr1', types are installed into the table and in doing so
> 'modifier_type::is_same' is called. The 'is_same' function cannot distinguish 
> between 'const const' and 'const' and therefore, the 'const const' type
> is compressed type into 'const'. Since all of this is done before the error
> checking in 'qual', the error is not caught. I looked through the 'lcc' code,
> and, unlike snoot,  it doesn't install types in 'dclr1'. Is there a reason
> why this line is there in snoot? Removing it fixes this bug, but will it 
> cause other problems?
> 	Mukund

Thanks for the bug report.

Don't be confused by different versions of lcc.  When you say, ``I
looked through the 'lcc' code,'' what version of lcc do you mean?

This is the relevant section of the version of lcc used for snoot:

		t = gettok();
		if (t == CONST || t == VOLATILE) {
			Type ty1;
			ty1 = ty = tnode(t, 0);
			while ((t = gettok()) == CONST || t == VOLATILE)
				ty1 = tnode(t, ty1);
			ty->type = dclr1(id, lev);
			ty = ty1;
		} else
			ty = dclr1(id, lev);
		ty = tnode(POINTER, ty);
		break;

Note that the behavior is exactly the same as that of the snoot code:
it doesn't call qual() to do the qualification, so it doesn't have the
error checking qual() does.

So snoot inherited this bug from the version of lcc it used.  For
SUIF, we needed very high-level information, not the lower-level
representation normally produced by lcc.  So we removed most of the
internal datastructures and had the lcc parser generate SUIF directly.
Unfortunately, that means that it was impractical to change snoot when
a new version of lcc came out that had substantial internal changes.
So we're stuck with a version of the lcc parser from several years
ago.

As far as fixing this particular problem in snoot goes, you can't just
call qual() directly here because qual() installs the type it creates.
This code is creates qualified versions of the void type, then figures
out the correct type and patches the pointer of the qualification node
to point to the real type later when it figures out what that would
be.  This wouldn't work if the qualified versions of void were
installed, because the installation might use a qualified void type
that was already installed and used for something else -- so patching
the pointer would mess up the other uses that really needed the
qualified void type.

I'll fix snoot to do the checking for redundant modifiers correctly
here and that fix will be in the next release of snoot.  But unless I
get a special request, I won't bother sending out a patch before the
next release just for this.  After all, this bug only allows some
technically illegal input programs to compile ok, ignoring the
redundant qualifications.

        --Chris

From: Mukund Raghavachari <mrm@CS.Princeton.EDU>
Date: Tue, 11 Jun 1996 12:16:12 -0400
Subject: Minor bug
Message-Id: <199606111616.MAA17691@dynastar.CS.Princeton.EDU>

Hi,
	This is regarding snoot. Currently, declarations of the form:
		'int * const const volatile', 
do not give an error as they should. The reason for this is that in the
function 'dclr1', types are installed into the table and in doing so
'modifier_type::is_same' is called. The 'is_same' function cannot distinguish 
between 'const const' and 'const' and therefore, the 'const const' type
is compressed type into 'const'. Since all of this is done before the error
checking in 'qual', the error is not caught. I looked through the 'lcc' code,
and, unlike snoot,  it doesn't install types in 'dclr1'. Is there a reason
why this line is there in snoot? Removing it fixes this bug, but will it 
cause other problems?
	Mukund