ambiguous why?

Hank Dietz hankd at pur-ee.UUCP
Fri Apr 8 02:07:38 AEST 1988


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?



More information about the Comp.lang.c mailing list