Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Pre And Post Increment Operator Output |
| Date | 2012-07-05 09:08 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <jt43jn$o7j$1@dont-email.me> (permalink) |
| References | (4 earlier) <lnipek8bri.fsf@nuthaus.mib.org> <js1gf5$l7v$1@dont-email.me> <0.06d3eacd14619c86d384.20120622143458BST.87ehp7o4fx.fsf@bsb.me.uk> <jt291q$14k$1@dont-email.me> <jt2dj8$qo7$1@dont-email.me> |
On 7/4/12 5:46 PM, Eric Sosman wrote:
>
> Even if every CPU of interest can generate a consistent result
> for such a case, it's not a given that two different CPU's -- even
> different steppings of "the same" CPU -- will yield the same answer.
>
> Also, let's rewrite your function just a little:
>
> int foo(int *a, int *b) {
> return *a == *++b;
> }
>
> What "should" the result be when a == b? "Should" *a yield the
> original or the incremented value, and why? Or how about
>
> int foo(int *a, int *b, int *c) {
> return *a * *++b + *a * *++c;
> }
>
> ... when a==b and a==c? May the compiler apply the distributive
> law and do common sub-expression elimination? Why, or why not,
> and what are the implications for optimizers?
>
If the variation was just based on the unspecified order of operations,
but CPUs would always properly execute it, then I suspect the standard
would have given the multiple modification UNSPECIFIED behavior, not
UNDEFINED behavior, which has much less possible dire consequences.
One comment on your example
*a == *++b
will yield a different type of UB. ++b can NOT change the value of *a,
as we are changing b, the parameter/local variable, not the location
pointed to. If foo was called with &i as in my example, ++b has the
++operator is defined only for pointers to arrays, not for pointer to
scalars. If the original had been static i; then it is possible that i
is at the end of the memory segment in which it lives, and ++b may then
generate an address outside the segment bounds, which might cause a trap
either on the increment or on the deference, and if that doesn't happen,
the value retrieved surely is not what is desired.
Changing the *++ to ++* to bet back to the original case, which value *a
retrieves in *a == ++*b when a == b, if we hold to the ideals of the C
language, it would be unspecified, so a standard conforming
implementation could return either 1 or 0. Other languages prefer to
reduce undefined/unspecified behavior, and may state that the expression
SHALL be evaluated left to right (for example) and then *a would always
get the previous value, so the expression would always be evaluated as 0.
In the second expression, since C doesn't specify order, the compiler
can apply the distributive law assuming that the overflow behavior of
the machine makes it applicable (for example, if we were dealing with
floats, then it wouldn't apply). The language which tries to define
order of operations would have problems with the second, as the ++*b
changes the meaning of the second *a, so it would need to disallow the
use of the distributive law (one reason why C doesn't specify order of
operations).
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Pre And Post Increment Operator Output Yogesh Yadav Pacheria <yogeshpacheria@gmail.com> - 2012-06-21 12:56 -0700
Re: Pre And Post Increment Operator Output Paul N <gw7rib@aol.com> - 2012-06-21 13:08 -0700
Re: Pre And Post Increment Operator Output Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-21 16:52 -0400
Re: Pre And Post Increment Operator Output John Gordon <gordon@panix.com> - 2012-06-21 20:11 +0000
Re: Pre And Post Increment Operator Output Andrew Cooper <amc96@cam.ac.uk> - 2012-06-21 21:29 +0100
Re: Pre And Post Increment Operator Output "BartC" <bc@freeuk.com> - 2012-06-21 22:08 +0100
Re: Pre And Post Increment Operator Output Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-21 17:32 -0400
Re: Pre And Post Increment Operator Output "BartC" <bc@freeuk.com> - 2012-06-22 00:00 +0100
Re: Pre And Post Increment Operator Output Keith Thompson <kst-u@mib.org> - 2012-06-21 16:51 -0700
Re: Pre And Post Increment Operator Output "BartC" <bc@freeuk.com> - 2012-06-22 11:09 +0100
Re: Pre And Post Increment Operator Output nick_keighley_nospam@hotmail.com - 2012-06-22 05:36 -0700
Re: Pre And Post Increment Operator Output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-22 14:34 +0100
Re: Pre And Post Increment Operator Output Les Cargill <lcargill99@comcast.com> - 2012-06-22 12:45 -0500
Re: Pre And Post Increment Operator Output nick_keighley_nospam@hotmail.com - 2012-06-25 00:27 -0700
Re: Pre And Post Increment Operator Output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 14:32 +0100
Re: Pre And Post Increment Operator Output Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 09:42 -0400
Re: Pre And Post Increment Operator Output Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 11:33 -0400
Re: Pre And Post Increment Operator Output Richard Damon <news.x.richarddamon@xoxy.net> - 2012-07-04 16:27 -0400
Re: Pre And Post Increment Operator Output Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-04 17:46 -0400
Re: Pre And Post Increment Operator Output Richard Damon <news.x.richarddamon@xoxy.net> - 2012-07-05 09:08 -0400
Re: Pre And Post Increment Operator Output "io_x" <a@b.c.invalid> - 2012-07-06 17:34 +0200
Re: Pre And Post Increment Operator Output Keith Thompson <kst-u@mib.org> - 2012-06-22 12:31 -0700
Re: Pre And Post Increment Operator Output Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-22 16:21 -0400
Re: Pre And Post Increment Operator Output Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-21 21:06 -0400
Re: Pre And Post Increment Operator Output Noob <root@127.0.0.1> - 2012-06-22 13:30 +0200
Re: BartC (was: Pre And Post Increment Operator Output) "BartC" <bc@freeuk.com> - 2012-06-22 13:06 +0100
Re: Pre And Post Increment Operator Output Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-22 09:26 -0400
Re: Pre And Post Increment Operator Output "Bartc" <bc@freeuk.com> - 2012-07-01 16:33 +0100
Re: Pre And Post Increment Operator Output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-01 17:15 +0100
Re: Pre And Post Increment Operator Output "Bartc" <bc@freeuk.com> - 2012-07-01 18:45 +0100
Re: Pre And Post Increment Operator Output Keith Thompson <kst-u@mib.org> - 2012-07-01 13:03 -0700
Re: Pre And Post Increment Operator Output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-02 00:18 +0100
Re: Pre And Post Increment Operator Output Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-06-24 23:45 +0300
Re: Pre And Post Increment Operator Output Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-24 09:15 -0700
Re: Pre And Post Increment Operator Output Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-06-24 23:54 +0300
Re: Pre And Post Increment Operator Output Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-24 15:12 -0700
Re: Pre And Post Increment Operator Output "BartC" <bc@freeuk.com> - 2012-06-25 11:00 +0100
Re: Pre And Post Increment Operator Output Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-25 13:53 -0700
Re: Pre And Post Increment Operator Output Keith Thompson <kst-u@mib.org> - 2012-06-21 15:17 -0700
Re: Pre And Post Increment Operator Output Yogesh Yadav Pacheria <yogeshpacheria@gmail.com> - 2012-06-21 21:03 -0700
Re: Pre And Post Increment Operator Output nick_keighley_nospam@hotmail.com - 2012-06-22 00:06 -0700
Re: Pre And Post Increment Operator Output Mark Bluemel <mark_bluemel@pobox.com> - 2012-06-22 08:30 +0100
Re: Pre And Post Increment Operator Output John Bode <jfbode1029@gmail.com> - 2012-06-22 09:18 -0700
Re: Pre And Post Increment Operator Output Keith Thompson <kst-u@mib.org> - 2012-06-22 12:36 -0700
Re: Pre And Post Increment Operator Output lawrence.jones@siemens.com - 2012-06-22 14:25 -0400
Re: Pre And Post Increment Operator Output "Heinrich Wolf" <invalid@invalid.invalid> - 2012-06-22 10:27 +0200
Re: Pre And Post Increment Operator Output Kenneth Brody <kenbrody@spamcop.net> - 2012-06-22 13:46 -0400
Re: Pre And Post Increment Operator Output Michael Press <rubrum@pacbell.net> - 2012-07-13 02:09 -0700
Re: Pre And Post Increment Operator Output Ian Collins <ian-news@hotmail.com> - 2012-06-22 23:11 +1200
Re: Pre And Post Increment Operator Output Mark Bluemel <mark_bluemel@pobox.com> - 2012-06-22 12:18 +0100
csiph-web