Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site druny.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxt!mhuxi!mhuxa!houxm!ihnp4!drux3!druny!ldg
From: ldg@druny.UUCP
Newsgroups: net.lang.c
Subject: Redeclaration of typedef names
Message-ID: <677@druny.UUCP>
Date: Sat, 27-Aug-83 11:46:36 EDT
Article-I.D.: druny.677
Posted: Sat Aug 27 11:46:36 1983
Date-Received: Mon, 29-Aug-83 02:16:29 EDT
Organization: AT&T Information Systems, Denver
Lines: 47


In my opinion, the problem of typedef redefinition stems from two
sources: 1) lack of specification, and, 2) compiler complexity.

Section 11.1 of the C Reference Manual (Ritchie) describes a scenario
in which a typedef identifier is redefined as a simple ordinary
identifier: 
	typedef float distance;
	...
	{
		auto int distance;
		...
The point made is that "int" must be present, otherwise we would have
a declaration with no declarator and type "distance. Clearly, the
physical position of "distance" also plays a role here. Should we
change the ordering of "int" and "distance" we would have an illegal
declaration with no declarator. If we had

		auto int a,b,c,distance,e,f;

should we expect a syntax error or a redeclaration to occur? It seems
the manual is lacking in this area. There should be no problem with using
"distance" as a structure or union tag, since these are kept in a logically
separate list, as the manual says. However, enumeration tags and enumerators
are like ordinary identifiers and would conflict with an identical typedef
name declared in the same scope. Incidentally, I couldn't get the above
example from the manual to compile on any compiler.

I think it's fairly clear why the compiler can't correctly resolve a
valid redeclaration of a typedef. The C parser is generated from a YACC
grammar, and expects the lexical analyzer to distinguish between a
simple identifier and a declared typedef name. If instead this were not
done and typedef names were treated lexically like any other identifier,
then the grammar must dramatically increase in size in order to handle
parsing problems like "in a declaration, where does the type part end
and the declarator begin?". Things could even get more ambiguous:

	x;		/*  declaration or statement?		*/
	a = (f)(x);	/* function call or cast expression?	*/

So, because a typedef name is lexically distinct from an identifier
(which is the root of any declarator) it cannot syntactically assume
the role of a declarator in a declaration. In order to implement typedef
redeclaration in a way consistent with the current manual, I would think
the compiler maintainers would have to modify the semantic actions
performed in the production(s) allowing a declaration without a declarator
so that a new definition is associated with the typedef identifier.