C not LALR(1) & compiler bugs

[Doug Gwyn <gwyn>]

>                        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?

> All I have to say, concerning the design of C's syntax, is "Oops".

Unlike the toy languages they teach you about in school, C evolved
as a living language, in direct response to the perceived needs of
its users.  Typedefs were a fairly recent innovation; it is a minor
miracle that they fit into the language as well as they do.

> I also realized that this, combined with that real spiffy feature
> of C that identifiers are the same if the first 8 characters are
> the same, could be combined to really confuse C compilers.

That is not a current C language rule.  It was enforced in the
original PDP-11 implementation because on that architecture it
was important to keep data space requirements small.

> Isn't it strange that it seems better for the compiler to be wrong?
> 
> Doesn't that make you wonder if something is SERIOUSLY wrong with C?

It makes me think there is something seriously wrong with the
programmer who relies on automatic 8-character truncation of symbolic
names to make his code work.  Also, for the particular feature you're
griping about to even come into play, your code has to violate
several rules of good style.  In practice, competent C programmers
NEVER write code where the so-called "ambiguity" is an issue.

"If you want Ada, you know where to find it."