Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!brl-smoke!smoke!cottrell@NBS-VMS.ARPA
From: cottrell@NBS-VMS.ARPA (COTTRELL, JAMES)
Newsgroups: net.lang.c
Subject: C not LALR grammar
Message-ID: <1133@brl-smoke.ARPA>
Date: Wed, 19-Feb-86 16:22:43 EST
Article-I.D.: brl-smok.1133
Posted: Wed Feb 19 16:22:43 1986
Date-Received: Sun, 23-Feb-86 05:53:33 EST
Sender: news@brl-smoke.ARPA
Lines: 27

> >                        A ( *B );
> > 
> >     If A has been defined as a typedef name, then the line is a
> >     declaration of a variable B to be of type "pointer to A."
> >     (The parentheses surrounding "*B" are ignored.)  If A is not
> >     a type name, then this line is a call of the function A with
> >     the single parameter *B.  This ambiguity cannot be resolved
> >     grammatically.
> >         C compilers based on UNIX' YACC parser-generator -- such
> >     as the Portable C Compiler -- handle this problem by feeding
> >     information acquired during semantic analysis back to the
> >     lexer.  In fact, most C compilers do some typedef analysis
> >     during lexical analysis.
> 
> Which is just fine.  There are many other cases where the symbol
> table must be consulted to determine how to handle a construct
> (scope rules, etc.).  Nobody promised that C grammar would be
> strictly LALR(1)-parsable.  What is your problem?

Amen! At least it's not as bad as FORTRASH where when you see
the string `DO 10 I =' you don't have to look ahead for the comma
to tell you it's really a DO statement rather than an assign to the
variable `DO10I'. This freaked me out when I heard about it. YUK!

	jim		cottrell@nbs
*/
------