tim (03/28/83)
The portable C compiler tries to be too smart for its own good in lexical analysis. Consider the following fragment: int i, *ptr; ptr = &i; /* ptr is set to address of i */ ptr=&i; /* same as above */ The second statement is lexically identical to the first; however, PCC decides that it should be parsed as: ptr =& i ; Of course, the =& operator is from earlier versions of C, and is no longer valid, so PCC gives an error message and assumes that what you meant to say was "ptr &= i ;" which is a type mismatch, as well as being different from the real meaning. The token "=&" became invalid. Instead of being removed from the lexical analyzer, it was left in as an "error condition". This is immensely stupid; the whole reason for getting rid of it was to remove the ambiguity that is still causing the problem. Tim Maroney
crc (03/29/83)
Leaving '=&' in the language was done so that the compiler will catch old code. It will I believe, be removed at some point in the future. Note that there are still v6 and v7 programs lurking in the darkness. Infact, I just found 8 '=+' in a directory of old programs. I better go exterminate them. -bye.
guy (03/31/83)
To be precise, as of USG UNIX 5.0 =+, =-, =<general operator> have been
sent to the great Bit Bucket in the Sky, along with
int x 5; /* should be int x = 5; */
We've had over 2 years to catch this; lint and pcc have been bitching
to us all that time. If there's still code out there that uses this,
except on systems which have vanilla V6 (which means no Standard I/O,
so they're really out in the cold), it should be changed because someday
it may be gone permanently.
Guy Harris
RLG Corporation
{seismo|mcnc|we13}!rlgvax!guyguy (03/31/83)
BTW, the official syntax in V7 is &=, not =&. The only compiler that
refuses to accept =<operator> is the compiler that came with V6; the
Photo 6, PWB 1.0, V7, and USG compilers all accept the new form, and all
the PCC implementations warn you about the old form.
Guy Harris
RLG Corporation
{seismo|mcnc|we13}!rlgvax!guy