Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site wjh12.UUCP
Path: utzoo!linus!vaxine!wjh12!kendall
From: kendall@wjh12.UUCP (Kendall)
Newsgroups: net.lang.c
Subject: Redeclaration of typedef names
Message-ID: <313@wjh12.UUCP>
Date: Fri, 26-Aug-83 00:35:21 EDT
Article-I.D.: wjh12.313
Posted: Fri Aug 26 00:35:21 1983
Date-Received: Sat, 27-Aug-83 20:23:52 EDT
Organization: Delft Consulting Corp., New York
Lines: 32

Once a name has been defined as a typedef type, it is very difficult
to redeclare it in an inner block.  The manual states (section 8.8),

	Within the scope of a declaration, each identifier appearing
	as part of any declarator therein become [sic] syntactically
	equivalent to the type keyword naming the type associated with
	the identifier ....

This statement has a couple of exceptions.
(1) struct/union/enum tags are in a seperate namespace and do not
    conflict with typedef names.  It is common practice, and
    reasonable, to depend on this.  struct/union member names seem to
    work the same way in the Ritchie and Portable compilers.
(2) In both compilers, one can redeclare a typedef name in the normal
    namespace, and in an inner scope, (only) by redeclaring the name
    as either a formal parameter or an enum member.  I guess one is
    allowed to redeclare a typedef name in those contexts because it
    is syntactically unambiguous to do so.

The way I see it, exception (1) is a reasonable exception, and should
be viewed as an omission in the manual.  Exception (2), however,
strikes me as a compiler bug, even in both compilers.  It is a strange
thing to depend on, particularly since lint will complain.  If
exception (2) wasn't there, one could rest secure in the knowledge
that typedef names cannot be redeclared.

Questions:  does any program depend on exception (2)?  Should it be
stricken from the language, since the manual implicitly prohibits it
and since the language would be cleaner without it?  Does anyone care?

	Sam Kendall			{allegra,ihnp4}!wjh12!kendall
	Delft Consulting Corporation	  decvax!genrad!wjh12!kendall