Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ptsfa!ihnp4!homxb!mhuxt!m10ux!mnc
From: mnc@m10ux.UUCP (Michael Condict)
Newsgroups: comp.lang.c
Subject: Re: C sintax
Message-ID: <501@m10ux.UUCP>
Date: 2 Feb 88 19:47:47 GMT
References: <7072@brl-smoke.ARPA> <7160@brl-smoke.ARPA> <3932@hoptoad.uucp> <4079@june.cs.washington.edu> <4080@june.cs.washington.edu> <548@gtx.com>
Organization: AT&T Bell Labs, Murray Hill
Lines: 32

In <548@gtx.com>, al@gtx.com (Alan Filipski) writes:
> I'll stick my neck out and say I don't think there ARE any syntactic
> ambiguities in C. (there are, of course, the semantic ones resulting
> from undefined order of evaluation).  The potential ambiguities such
> as the dangling else and those involving the comma operator are solved
> by fiat.
> 
> Are there any syntactic ambiguities K&R didn't resolve?
> 
>     ----------------------------------------------------------------------
>    | Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
>    | {ihnp4,cbosgd,decvax,hplabs,amdahl}!sun!sunburn!gtx!al (602)870-1696 |
>     ----------------------------------------------------------------------

Yes, there are, at least if you mean context-free ambiguities.  That is,
without a symbol table or other context-sensitive techniques, the following
is ambiguous in C:

	{ t (x); ... }

If ``typedef ... t;'' appeared previously then this is a declaration of a var
named x of type t, otherwise it is a call to a function t with argument x.
This is more than a theoretical problem, since it implies that any parser
for C must include a symbol table package.  Thus if you wish to provide a
black-box C parser module to be used in multiple applications, either each
application must agree to use the symbol table package embedded in the parser,
or the application must redundantly provide its own symbol table.  Neither
prospect is very appealing to me.
-- 
Michael Condict		{ihnp4|vax135|cuae2}!m10ux!mnc
AT&T Bell Labs		(201)582-5911    MH 3B-416
Murray Hill, NJ