Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!munnari!basser!john From: john@basser.oz (John Mackin) Newsgroups: net.unix-wizards Subject: Re: C compiler implements wrong semantics Message-ID: <511@basser.oz> Date: Mon, 3-Feb-86 00:38:39 EST Article-I.D.: basser.511 Posted: Mon Feb 3 00:38:39 1986 Date-Received: Wed, 5-Feb-86 00:52:26 EST References: <2147@brl-tgr.ARPA> Reply-To: john@basser.oz (John Mackin) Organization: Dept of Comp Sci, Uni of Sydney, Australia Lines: 102 Summary: Please, please, please, RTFM! I originally wrote the following as a piece of mail to the poster of the article, but then I thought someone might be led to believe some of the hideous misstatements he made, so I am following-up instead... In article <2147@brl-tgr.ARPA> NEVILLE%umass-cs.csnet@csnet-relay.arpa (Neville D. Newman) writes: > While digging through the guts of the portable C compiler, i noticed > that it produced exactly the same code for two statements that i think > have different semantics. > According to my C references, the unary > operators have precedence over binary operators (and are evaluated right > to left). First problem. ``my C references'', ``my books'' (below): what are these meaningless terms? WHAT are you using as a reference? There is only ONE book that should be referred to in a case like this: ``The C Programming Language,'' by Brian W. Kernighan and Dennis M. Ritchie, Prentice-Hall, 1981, commonly referred to as ``K&R''. That is the document that defines the language, at least until the ANSI C standard is produced; and even then there will be ANSI C and K&R C, unless I miss my guess. If you are digging around in the internals of a C compiler and you haven't read K&R until you more or less know it by heart, go do so, and you don't need to read any more of this news item. If I seem to be belaboring the obvious, the reason will become clear very soon. > The rule for pre- and post-increment (and -decrement) operators > is, of course, that a++ changes the value of a after the value of the > term is used, so that the change is a side-effect. Correct. Read what you wrote ... ``IS A SIDE-EFFECT.'' Remember those words, we'll have cause to refer to them shortly. > ++a, on the other > hand changes the value of a before the term is used and is therefore > entirely equivalent to (a += 1) or (a = a+1). If by this you are trying to claim that the change to a in this case is NOT a side-effect, you're wrong. A side-effect is a change to a variable ``as a by-product of the evaluation of an expression'': K&R, page 50. > According to my books, if a is 5, then (a++ + a) ought to evaluate to 11. WHAT BOOKS? Any book which implies or states any such thing is just plain WRONG! Read K&R, page 50 (Section 2.12): In any expression involving SIDE EFFECTS, there can be subtle dependencies on the order in which variables taking part in the expression are stored. [Emphasis mine.] I won't quote it at greater length, it'd be too much to type, but they make it perfectly clear. What that expression ``ought to evaluate to'' is NOT DEFINED. The implementer of a given C compiler is free to evaluate it as they wish. Even lint knows that; applying it to your test program gives: xx.c(9): warning: a evaluation order undefined xx.c(12): warning: a evaluation order undefined xx.c(15): warning: a evaluation order undefined xx.c(18): warning: a evaluation order undefined xx.c(23): warning: a evaluation order undefined xx.c(26): warning: a evaluation order undefined xx.c(29): warning: a evaluation order undefined xx.c(32): warning: a evaluation order undefined > So the questions for the day are: Is pcc "right" because it is sort of the > defacto standard? (i have a friend who claims that BNF and such are useless, > the compiler is the only definition of a language that counts) There are cases, particularly with reference to the cpp, where this argument is valid. However, in this case it doesn't enter into the discussion, because the result is NOT DEFINED. > Is this > discrepancy between Unix C's behaviour and description already widely known > and carefully worked around? There IS no discrepancy. > Should i attempt to fix it and possibly break > some code or leave it alone for old time's sake? Like the old adage says: ``If it's not broken, DON'T fix it.'' > The pre-increments should be give results of 12 on all systems, > or else there's a *bad* problem. INCORRECT! The order of evaluation of such things IS NOT DEFINED! I'm sorry if I've been a bit over-vehement about this, but it does upset me when people don't read the documents in the case... John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia {seismo,ukc,mcvax,ubc-vision,prlb2}!munnari!basser.oz!john john%basser.oz@SEISMO.CSS.GOV CSNET: john@basser.oz