Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Old-fashioned assignment operators (was Re: braces
Message-ID: <750@auspex.UUCP>
Date: 17 Dec 88 23:01:59 GMT
References: <9076@smoke.BRL.MIL> <14020049@hpisod2.HP.COM> <212@UNIX386.Convergent.COM> <2151@uokmax.UUCP> <2155@uokmax.UUCP> <4421@xenna.Encore.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 33

>I think Gwyn speaks a little too soon about nuking old interpretations
>of =op, an incredibly boring find on both 4.3 and SYSVR3 sources
>reveals several instances of =op stubbornly remain (I can't say this
>was exhaustive, it was however exhausting):
>
>	all over Pascal in 4.3bsd

Well, yeah, Berkeley hasn't (yet - at least not as of 4.3) nuked it. 
Sun *has*, however, nuked it in SunOS4.0, so I presume the equivalent
code has long since been fixed in the Sun Pascal compiler.  I suspect
Berkeley will nuke it at some point (if they haven't already done so in
4.3-tahoe).

>	lex/sub1.c (both 4.3 and SysV)

That's inside debugging code; presumably, if somebody ever turns it on,
they'll have to fix it....

>	mkfs (SYSVR3)

That's inside the "#ifdef RT" stuff; I don't know how vigorously UNIX/RT
is being supported, but that code doesn't get compiled under regular UNIX.

>I agree they could/should be cleaned up but it was a useful exercise
>before believing that the compiler's semantics could be safely
>changed. (Note: this is in everyone's code derived from either 4.3 or
>SYSV so Unix systems which have changed the compiler semantics and not
>the code almost certainly have introduced bugs into their systems.)

Well, S5 ("Release 1", I think) *did* change the compiler semantics;
since the code in question either doesn't appear in S5 (Pascal) or
doesn't get compiled in S5 ("lex", "mkfs"), they definitely didn't
introduce bugs into their systems.