[net.lang.c] typedef bug summary

tps@sdchem.UUCP (Tom Stockfisch) (07/24/86)

Subject: typedef bug summary

ORIGINAL ARTICLE:

All the C compilers I have access to (4.2 and 4.3 on VAXes, and 4.2 on
Celerity) reject the following legitimate program.  Try this out on your
compiler:

	typedef float	distance;

	main()
	{
	/*###6 [cc] illegal type combination%%%*/
		auto int	distance;

	/*###8 [cc] unknown size%%%*/
	/*###8 [cc] cannot recover from earlier errors: goodbye!%%%*/
	/*###8 [cc] syntax error%%%*/
	/*###8 [cc] warning: illegal combination of pointer and integer, op =%%%*/
		distance =	1;
		printf( "distance = %d\n", distance );
	}

The float typedef's scope should be hidden by the local int's declaration
so that the program *is* legal.  Lest you think this isn't guaranteed, this
program is actually an example from K&R p. 206.  It is also accepted by
the yacc grammar I got off the net based on the ANSI 4/85 draft.

So here's the question:  is this bug present in *all* pcc compilers, or at
least in a lot of compilers?  If so, I better stop using lower case letters
for typedefs to avoid clashes with local variables.

If people send me the results of this program using their compiler, I'll
post a summary of which compilers get it right, and which wrong.

--Tom Stockfisch, UCSD Chemistry

SUMMARY OF RESPONSES:

RESPONDENT		COMPILERS WITH BUG		COMPILERS WITHOUT BUG

Andrew Koenig
ark@alice.UucP		all pcc compilers

Dan Jones		(pcc based) Unisoft		Green Hills

jjr@sas.UUCP (Jack Rouse) (07/27/86)

The problem described by Tom Stockfisch, where a typedef identifier cannot be 
reused as a variable identifier in a nested scope is common to many C compilers
which use a formal grammar for parsing.  In order to handle ambiguities in the
C grammar, it is necessary for these compilers to regard typedef names and
normal identifiers as different lexical types.  Consider the following code:
	int i, bar;
	...
	i = (foo)&bar;
If foo is an int variable, the last statement performs a bitwise and of foo and
bar.  If foo is a typedef name (as in "typedef int foo;"), however, then the
last statement takes the address of bar and casts it to type foo.

To resolve this ambiguity, PCC derived compilers pass information back from the
parser to the lexical scanner when a typedef name is created so that it will
not be treated as a regular identifier.  What PCC has neglected to do, however,
is provide a means to redeclare the name in a inner scope.
-- 
--
Jack Rouse, SAS Institute Inc., Box 8000, Cary, NC 27511  USA
USENET:  mcnc!rti-sel!sas!jjr          TELCO :  (919) 467-8000