Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Modifying Typedefs (And Implementing Them)
Message-ID: <1990Sep18.165524.17047@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <1990Sep14.213822.4828@uunet!unhd>
Date: Tue, 18 Sep 90 16:55:24 GMT

In article <1990Sep14.213822.4828@uunet!unhd> al@uunet!unhd (Anthony Lapadula) writes:
>   typedef int  INT;
>   typedef char CHAR;
>   ... { ...
>       unsigned INT foo1;
>       extern   INT foo2;
>       extern   INT (CHAR);

The 3.5.2 constraints outlaw foo1, but the other two declarations are legal.
Typedef names follow block-structured scope rules and can be hidden by
variable declarations in inner blocks.

Your grammar actually *has* to include the 3.5.2 constraints to some degree;
you can't leave them until later, because

	typedef unsigned U;
	... { ...
		short U = 2;		/* !!! */

is perfectly legal C.  Typedef names don't mix with other type specifiers,
so `!!!' is a perfectly legal declaration of a variable named `U' with
type `signed short int' which is initialized to 2.

Barf.

>... lexer get the candidate identifier, asks the symbol table
>if it is currently a typedef-name, and returns, e.g., TYPEDEF or IDENTIFIER
>to the grammar.
>
>Doesn't the lexer have to know more?  In my third example, the
>lexer needs to know that CHAR is a candidate variable, even though it
>is currently a typedef-name.  How is this implemented?

The lexer really can't know, in these cases, what's wanted.  What you have
to do is mung your parser so that (a) it knows that typedef names don't mix
with the other specifiers like `unsigned' and (b) in some (not all!) places
it takes typedef names as alternatives to identifiers, with later processing
treating them as equivalent.  There is just no other way to cope with the
`!!!' example.

>As an aside, gcc 1.37.1 rejects my first example
>   unsigned INT foo1;
>but accepts
>   INT unsigned foo1;

Sounds like a bug.  (Although the gcc folks have a tendency to call such
things "features" any time they don't like what the standard says.)
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry