Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!hankd
From: hankd@pur-ee.UUCP (Hank Dietz)
Newsgroups: comp.lang.c
Subject: Re: ambiguous why?
Message-ID: <7852@pur-ee.UUCP>
Date: 7 Apr 88 16:07:38 GMT
References: <1303@PT.CS.CMU.EDU> <22997@bbn.COM> <1320@PT.CS.CMU.EDU>
Organization: Purdue University Engineering Computer Network
Lines: 20
Summary: Not really; but there's an interesting side issue

Your compiler said it was ambiguous because it didn't know whether you
gave it old-style C or new C... not because it is ambiguous in a formal
parsing/lexical analysis sense....  In fact, *a+=*b has only one legal
interpretation because if the + is taken as an operator unto itself,
then there is no legal (error-free) interpretation of the =.

Now that X3J11 has bid final farewell to the =op stuff, it is sort-of
a moot point, but has anyone else noticed that the usual confusion
with =op can be resolved by using TYPE infromation?  For example:

a=*b;		This is a*=b; iff a and b are types which can be
		multiplied, i.e., not pointers, whereas it is
		a=(*b); if b is a pointer.
a=&b;		Similar observation about type-viability of a&b
		versus &b....
a=-b;		Generally ambiguous, but not if we are dealing
		with unsigned quantities (e.g., pointers).

Does anyone know of a compiler which attempts type-based
disambiguation of the old-fashioned assignment operators?