rmtodd@uokmax.UUCP (Richard Michael Todd) (12/17/88)
In article <2151@uokmax.UUCP> randy@uokmax.UUCP (Longshot) writes: >As an interesting aside, the cc here on our Multimax will generate warnings for >lines like: > > x=-y; /* x = -y or x =- y? */ > >In other words, and math operator that can be combined with = can produce an >error. This will happen with +,-, *, and any others that fit the bill. Now, I >have yet to hard-test it to see which case it generates. Has anyone had >similiar messages, and checked further? Script started on Fri Dec 16 16:06:15 1988 % cat foo.c main() { int x,y; x = 3; y = 4; x=-y; printf("%d\n",x); } % cc foo.c "foo.c", line 5: warning: old-fashioned assignment operator % a.out -1 % ^D script done on Fri Dec 16 16:06:40 1988 It seems to be interpreting "=-" as "-=". The message warns of an "old-fashioned" assignment operator. There's an interesting bit of history here. Back around 6th Edition Unix (I think) the augmented assignment operators in C were written as =+, =-, etc, not "+=" like we do today. Unfortunately that caused an ambiguity problem: does x=-y mean x = -y or x =- y? That, I believe, is why the operator syntax was changed circa 7th Edition. The compilers were changed to accept the old syntax "=-" but issue a warning. The question I have is, what exactly *is* the correct interpretation of x=-y in modern C? As mentioned before, the Encore cc interprets it as augmented assignment. The compiler I use on my PC interprets it as assigning -y to x. Which interpretation is right? What does the ANSI C standard say about this? Of course, the existence of compilers that interpret this line differently means that if you want your code to be portable, you *must* include proper spaces; if you want to assign -y to x, you must say "x = -y" if you want your code to work everywhere. Finally, I question why this business of checking for old-fashioned assignment operators is still in Unix C compilers. After all, V7 came out around 10 years ago! Does anyone really have around any code that hasn't been converted to the new syntax by *now*? -- Richard Todd Fido:1:147/1 USSnail:820 Annie Court,Norman OK 73069 Try one of these: rmtodd@chinet.uucp, rmtodd@killer.dallas.tx.us, rmtodd@uokmax.ecn.uoknor.edu or ...!sun!texsun!uokmax!rmtodd. "MSDOS is a Neanderthal operating system" - Henry Spencer
ark@alice.UUCP (Andrew Koenig) (12/17/88)
In article <2155@uokmax.UUCP>, rmtodd@uokmax.UUCP (Richard Michael Todd) writes: > The question I have is, what exactly *is* the correct interpretation of > x=-y in modern C? As mentioned before, the Encore cc interprets it as The correct modern interpretation is x=(-y). See ``C Traps and Pitfalls,'' page 8. -- --Andrew Koenig ark@europa.att.com
bzs@Encore.COM (Barry Shein) (12/18/88)
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 lex/sub1.c (both 4.3 and SysV) mkfs (SYSVR3) Most of these seemed to use a space to dismabiguate and almost certainly intended V6 semantics as they're utilities that date back to around then. There might be more but that's enough to make the point. 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.) -Barry Shein, ||Encore||
guy@auspex.UUCP (Guy Harris) (12/18/88)
(Wow, a C question in comp.unix.*, rather than the other way around!) > The question I have is, what exactly *is* the correct interpretation of >x=-y in modern C? In sufficiently modern C, the interpretation is "assign the negative of the value of 'y' to 'x'". >What does the ANSI C standard say about this? The dpANS says "=-" should not be interpreted as an assignment operator (and the final standard, once it exists, will almost certainly say the same thing). The (non-dpANS-conformant) C compilers AT&T has distributed with System V releases do not interpret it as such, and more C compilers are picking this up (for instance, in SunOS 4.0, support for "old-style assignment operators" went away).
guy@auspex.UUCP (Guy Harris) (12/18/88)
>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.
henry@utzoo.uucp (Henry Spencer) (12/18/88)
In article <2155@uokmax.UUCP> rmtodd@uokmax.UUCP (Richard Michael Todd) writes: > The question I have is, what exactly *is* the correct interpretation of >x=-y in modern C? ... The old-style assignment operators are long gone. =- is the assignment operator followed by the unary-negation operator. > Finally, I question why this business of checking for old-fashioned >assignment operators is still in Unix C compilers. After all, V7 came >out around 10 years ago! Does anyone really have around any code that hasn't >been converted to the new syntax by *now*? You would be surprised at the magnitude of the dusty-deck problem. There are undoubtedly sites that are still running ten-year-old *binaries*, never mind sources. I fear that it is probably still a good idea for compilers to issue a warning message. -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
chris@mimsy.UUCP (Chris Torek) (12/18/88)
In article <4421@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >... an incredibly boring find on both 4.3 and SYSVR3 sources >reveals several instances of =op stubbornly remain .... The 4.3BSD-tahoe C compiler no longer supports =op `old fashioned assignemnt operators', so all the cruft found in 4.3BSD has been fixed. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bzs@Encore.COM (Barry Shein) (12/19/88)
Well, I am heartened to hear that =op is being removed rapidly. I am all in favor of doing this and moving on to ANSI semantics, I was just pointing out that it's a little early to flame folks who haven't changed their compiler yet since recent source releases still contain such code (albeit in rare and obscure places as Guy Harris pointed out.) Now, back to the indent/echo wars...sorry for the interruption. -Barry Shein, ||Encore||
der@sfmag.UUCP (D.Rorke) (12/29/88)
> The question I have is, what exactly *is* the correct interpretation of > x=-y in modern C? As mentioned before, the Encore cc interprets it as > augmented assignment. The compiler I use on my PC interprets it as assigning > -y to x. Which interpretation is right? What does the ANSI C standard say > about this? From Appendix C of the Second Edition of K & R: "The old assignment operators like =+ are truly gone." > Of course, the existence of compilers that interpret this line differently > means that if you want your code to be portable, you *must* include proper > spaces; if you want to assign -y to x, you must say "x = -y" if you want > your code to work everywhere. In this case the use of spaces is somewhat of a moot issue. Even if all compilers interpreted x=-y correctly (assign -y to x), using x = -y would still be preferable because the spacing enhances readability (my two cents worth on coding style). Of course, the existence of old, brain-dead compilers means that if you want your code to work EVERYWHERE you have to do lots of things like avoid the use of "enum" and "void", and treat only the first eight characters of an internal name as significant. In general I'm in favor of using useful features of the language which most compilers have supported for years. I think extending the definition of portability to mean "must use only the subset of features supported by every old compiler in existence" is a mistake. Let the person compiling the code worry about having a 20th century compiler. Of course there are exceptions to this; for instance you may have a specific customer that can't be expected to get a modern compiler because none exists for obscure architecture X that he is using. ANSI C will make life much easier in this respect. I am glad to see that the committee had the courage to require support for certain features of the language that are not currently universally supported. This will encourage the development of ANSI conformant code (since the standard doesn't prevent you from using useful new features) and will therefore actually enhance portability. The is in contrast to other standards efforts, particularly in the operating systems area, which standardize on the least common denominator of existing implementations, thereby creating a standard which doesn't provide enough functionality to write many useful applications. > Finally, I question why this business of checking for old-fashioned > assignment operators is still in Unix C compilers. After all, V7 came > out around 10 years ago! Does anyone really have around any code that hasn't > been converted to the new syntax by *now*? In some cases the compiler doing the checking may be rather old itself, dating back to when this was a real issue. I agree that new compilers shouldn't need to check. New compilers shouldn't have to support ancient code just as new code shouldn't have to worry about ancient compilers. > -- > Richard Todd Fido:1:147/1 USSnail:820 Annie Court,Norman OK 73069 > Try one of these: rmtodd@chinet.uucp, rmtodd@killer.dallas.tx.us, > rmtodd@uokmax.ecn.uoknor.edu or ...!sun!texsun!uokmax!rmtodd. > "MSDOS is a Neanderthal operating system" - Henry Spencer Dave Rorke att!attunix!der