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