Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Pre And Post Increment Operator Output |
| Date | 2012-07-04 17:46 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <jt2dj8$qo7$1@dont-email.me> (permalink) |
| References | (3 earlier) <js092m$pov$1@dont-email.me> <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> |
On 7/4/2012 4:27 PM, Richard Damon wrote:
> On 6/22/12 9:34 AM, Ben Bacarisse wrote:
>>
>> I've never liked the view that anything can happen with undefined code;
>> it sounds too much like a cheap pedagogical trick to say that the above
>> could format your drive.
>
> One issue with C, is that when C was first being defined, computer
> architectures could have some strange rules with limitations on things
> like writing to and reading from a given location sequentially could
> cause weird results, sometimes totally random numbers, sometimes bus
> faults. Hardware designers didn't feel bad about putting restrictions on
> "silly" combinations of operations, or making the software have to wait
> for results to be done.
>
> C, in an effort to be as efficient as possible, choose to make some of
> these corner cases "undefined behavior" rather than make the compiler
> add test to the code to detect these. While in the example, it looks
> obvious of the double access, it real code, it might be better hidden
> with something like:
>
>
> int foo(int *a, int *b) {
> return ++*a + ++*b;
> }
>
> int main() {
> int i = 0;
> i = foo(&i, &i);
> printf("%d\n", i);
> }
>
> Where the code doing the dual access has two pointers, which happen to
> be set to point to the same spot elsewhere. Note that the function foo
> has well define behavior as long as a != b.
>
> Now, it is more common that the processor has logic to detect these sort
> of conflicts and rather than "getting it wrong", they stall the
> processor a bit so the answer can get there, but that took too much
> logic to be worth it in the earlier days.
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?
--
Eric Sosman
esosman@ieee-dot-org.invalid
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