Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!rochester!pt.cs.cmu.edu!andrew.cmu.edu!jm36#
From: jm36#@andrew.cmu.edu.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and overflow anomolies
Message-ID: <AUVhEFy00WAJzrQ0rP@andrew.cmu.edu>
Date: Fri, 17-Apr-87 20:17:05 EST
Article-I.D.: andrew.AUVhEFy00WAJzrQ0rP
Posted: Fri Apr 17 20:17:05 1987
Date-Received: Sat, 18-Apr-87 08:39:16 EST
Organization: Carnegie-Mellon University
Lines: 31
ReSent-Date: Fri, 17 Apr 87 22:16:02 edt
ReSent-From: postman#@andrew.cmu.edu
ReSent-To: nntp-xmit#@andrew.cmu.edu
Return-path: <jm36#@andrew.cmu.edu>
X-Andrew-Authenticated-as: 2971
X-Trace: MS Version 3.22 on sun3 host royalton, by jm36 (2971).
To: outnews#ext.nn.comp.lang.c@andrew.cmu.edu
In-Reply-To: <827@xanth.UUCP>
Beak: Is

> From: kent@xanth.UUCP (Kent Paul Dolan)
> Subject: Re: C and overflow anomolies
> 	The volatile declaration (I have no access to the dpANS, thank
> 	heaven, or I'd read that, too) certainly takes care of part of the
> 	problem, but it gives compiler writers license to break TONS of
> 	existing code, which depended on K&R's statement that splitting
> 	expressions into separate statements was enough to guarantee
> 	the evaluation order.  If I wrote (all "float" variables):
> 		temp = a - b;
> 		d = temp + c;
> 	in a piece of existing code to avoid the above overflow; the
> 	compiler writer is now free to elide temp from the code, then go
> 	back and rearrange to achieve:
> 		d = (a + c) - b;
> 	exactly what I was trying to avoid, unless I declare temp to be
> 	volatile.  Would _you_ like to go back through your site's existing C
> 	code and find all instances where that is why temp was put in the code,
> 	and add the appropriate volitile declaration?  ;-)
> 	

The ambitions compiler writer is NOT free to make this optimization.
There are such things as "sequence points" which occur between
statements.  The best that this could be optimized to is:

    d = +(a + c) - b;

With the additional restriction that "(a + c)" must be evaluated
before "b" if there is any possibility of side-effects between "b" and
either of "a" or "c".

				_.John