Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #22493 > unrolled thread

Pre And Post Increment Operator Output

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#22493 — Pre And Post Increment Operator Output

I tried this Code

int main()
{
   int i = 0;
   i = ++i + ++i + ++i;
   printf("%d",i);
}

Output should be 6 

But In GCC it's 7

How and plz tell the order of evalution of pre and post bot

Thanks in Advance

[toc] | [next] | [standalone]

#22495

On Jun 21, 8:56 pm, Yogesh Yadav Pacheria <yogeshpache...@gmail.com>
wrote:
> I tried this Code
>
> int main()
> {
>    int i = 0;
>    i = ++i + ++i + ++i;
>    printf("%d",i);
>
> }
>
> Output should be 6
>
> But In GCC it's 7
>
> How and plz tell the order of evalution of pre and post bot
>
> Thanks in Advance

The FAQ is at http://c-faq.com/ . Read it, you'll learn a lot from it.

[toc] | [prev] | [next] | [standalone]

#22500

On 6/21/2012 4:08 PM, Paul N wrote:
> On Jun 21, 8:56 pm, Yogesh Yadav Pacheria <yogeshpache...@gmail.com>
> wrote:
>> I tried this Code
>>
>> int main()
>> {
>>     int i = 0;
>>     i = ++i + ++i + ++i;
>>     printf("%d",i);
>>
>> }
>>
>> Output should be 6
>>
>> But In GCC it's 7
>>
>> How and plz tell the order of evalution of pre and post bot
>>
>> Thanks in Advance
>
> The FAQ is at http://c-faq.com/ . Read it, you'll learn a lot from it.

     Pay special attention to Question 3.2, which is almost
exactly what you asked.  Much of the rest of Section 3 pertains
to your issue, too.


-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#22496

In <8404c4f1-a3b7-46b7-ad9c-17de265f9aee@googlegroups.com> Yogesh Yadav Pacheria <yogeshpacheria@gmail.com> writes:

> int main()
> {
>    int i = 0;
>    i = ++i + ++i + ++i;
>    printf("%d",i);
> }

> Output should be 6 

No it shouldn't.  Using multiple increment operators in this way is
undefined.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#22498

On 21/06/2012 20:56, Yogesh Yadav Pacheria wrote:
> I tried this Code
> 
> int main()
> {
>    int i = 0;
>    i = ++i + ++i + ++i;
>    printf("%d",i);
> }
> 
> Output should be 6 
> 
> But In GCC it's 7
> 
> How and plz tell the order of evalution of pre and post bot
> 
> Thanks in Advance

You have provided a program which tries to update i more than once in a
sequence point.  This is strictly undefined by the C spec, so the
compiler is free to interpret it how it likes.

The disassembly (from GCC 4.6.3) looks a little like:

         movl    $7, %esi
         movl    $.LC0, %edi # String "%d\n"
         movl    $0, %eax
         call    printf

So what happens is that GCC calculates the value of i at compile time
and sticks it in as a constant.

~Andrew

[toc] | [prev] | [next] | [standalone]

#22502

"Yogesh Yadav Pacheria" <yogeshpacheria@gmail.com> wrote in message 
news:8404c4f1-a3b7-46b7-ad9c-17de265f9aee@googlegroups.com...
> I tried this Code
>
> int main()
> {
>   int i = 0;
>   i = ++i + ++i + ++i;
>   printf("%d",i);
> }
>
> Output should be 6
>
> But In GCC it's 7
>
> How and plz tell the order of evalution of pre and post bot

I agree it ought to be 6. Other C compilers, and even one or two other 
languages, give a result of 6.

But C allows compilers to evaluate expressions their own way, which may give 
undefined results when a variable is modified several times in the same 
expression. GCC must be one of those compilers that takes full advantage of 
that.

So you will have to rearrange the expression into separate statements (if it 
ever did anything useful to start with..).

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#22503

On 6/21/2012 5:08 PM, BartC wrote:
>
>
> "Yogesh Yadav Pacheria" <yogeshpacheria@gmail.com> wrote in message
> news:8404c4f1-a3b7-46b7-ad9c-17de265f9aee@googlegroups.com...
>> I tried this Code
>>
>> int main()
>> {
>>   int i = 0;
>>   i = ++i + ++i + ++i;
>>   printf("%d",i);
>> }
>>
>> Output should be 6
>>
>> But In GCC it's 7
>>
>> How and plz tell the order of evalution of pre and post bot
>
> I agree it ought to be 6.

     Nitwit.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#22510

"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
news:js03uf$sb3$1@dont-email.me...
> On 6/21/2012 5:08 PM, BartC wrote:

>> "Yogesh Yadav Pacheria" <yogeshpacheria@gmail.com> wrote in message
>> news:8404c4f1-a3b7-46b7-ad9c-17de265f9aee@googlegroups.com...

>>>   int i = 0;
>>>   i = ++i + ++i + ++i;
>>>   printf("%d",i);

>>> Output should be 6
>>>
>>> But In GCC it's 7

>> I agree it ought to be 6.
>
>     Nitwit.

Yet, given the OP's program, and a randomly assigned but unknown compiler,
what result would you put your money on, if you were obliged to gamble?

And once you know the result, would you gamble on the same compiler giving 
the exactly the same answer one more time?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#22512

"BartC" <bc@freeuk.com> writes:
> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
> news:js03uf$sb3$1@dont-email.me...
>> On 6/21/2012 5:08 PM, BartC wrote:
>
>>> "Yogesh Yadav Pacheria" <yogeshpacheria@gmail.com> wrote in message
>>> news:8404c4f1-a3b7-46b7-ad9c-17de265f9aee@googlegroups.com...
>
>>>>   int i = 0;
>>>>   i = ++i + ++i + ++i;
>>>>   printf("%d",i);
>
>>>> Output should be 6
>>>>
>>>> But In GCC it's 7
>
>>> I agree it ought to be 6.
>>
>>     Nitwit.
>
> Yet, given the OP's program, and a randomly assigned but unknown compiler,
> what result would you put your money on, if you were obliged to gamble?

Fortunately, we are not obliged to gamble.

> And once you know the result, would you gamble on the same compiler giving 
> the exactly the same answer one more time?

What would be the point?  Don't waste time guessing what the code might
do for a given implementation.  Just fix it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#22529

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnipek8bri.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>>> On 6/21/2012 5:08 PM, BartC wrote:
>>
>>>> "Yogesh Yadav Pacheria" <yogeshpacheria@gmail.com> wrote in message

>>>>>   int i = 0;
>>>>>   i = ++i + ++i + ++i;
>>>>>   printf("%d",i);
>>
>>>>> Output should be 6
>>>>>
>>>>> But In GCC it's 7
>>
>>>> I agree it ought to be 6.

>> And once you know the result, would you gamble on the same compiler 
>> giving
>> the exactly the same answer one more time?
>
> What would be the point?  Don't waste time guessing what the code might
> do for a given implementation.  Just fix it.

OK, so we fix it so that the result is ....? Any guesses?

Changing the erroneous code so that it stays within the rules:

int i = 0;
int t1,t2,t3;

t1=++i;
t2=++i;
t3=++i;
i=t1+t2+t3;
printf("%d",i);

Now gives a valid result. Which happens to coincide with the OP's 
expectations, and with what I said it *ought* to be (for which I was called 
a 'nitwit', even though I went on to explain why the OP wasn't getting that 
result), and in fact with what most of my compilers were already giving me 
anyway; presumably they were already using code along the same lines!)

However, the interesting question is, why anyone - outside c.l.c obviously - 
might think the output of the OP's original code might be 6, rather than any 
other number (or any other manifestation, according to previous threads 
along the same lines).

Or, are we not allowed to think or guess anything at all, simply because the 
C standard says the original expression has undefined behaviour?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#22535

On Friday, June 22, 2012 11:09:28 AM UTC+1, Bart wrote:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnipek8bri.fsf@nuthaus.mib.org...
> > "BartC" <bc@freeuk.com> writes:
> >>> On 6/21/2012 5:08 PM, BartC wrote:
> >>>> "Yogesh Yadav Pacheria" <yogeshpacheria@gmail.com> wrote in message


> >>>>>   int i = 0;
> >>>>>   i = ++i + ++i + ++i;
> >>>>>   printf("%d",i);
> >>
> >>>>> Output should be 6
> >>>>>
> >>>>> But In GCC it's 7
> >>
> >>>> I agree it ought to be 6.

no.

> >> And once you know the result, would you gamble on the same compiler 
> >> giving the exactly the same answer one more time?

no. Once I realised the program contained unnecessary undefined behaviour, I'd remove it. No guesses necessary.

> > What would be the point?  Don't waste time guessing what the code might
> > do for a given implementation.  Just fix it.
> 
> OK, so we fix it so that the result is ....? Any guesses?

"a suffusion of yellow"

> Changing the erroneous code so that it stays within the rules:
> 
> int i = 0;
> int t1,t2,t3;
> 
> t1=++i;
> t2=++i;
> t3=++i;
> i=t1+t2+t3;
> printf("%d",i);
> 
> Now gives a valid result. Which happens to coincide with the OP's 
> expectations, and with what I said it *ought* to be (for which I was called 
> a 'nitwit', even though I went on to explain why the OP wasn't getting that 
> result),

a bit harsh but you plainly don't understand what "undefined behavior" means.

> and in fact with what most of my compilers were already giving me 
> anyway; presumably they were already using code along the same lines!)

a more mysterious one was posted recently. It was only by looking at the assembler was anyone able to explain the result.

> However, the interesting question is, why anyone - outside c.l.c obviously - 
> might think the output of the OP's original code might be 6, rather than any 
> other number (or any other manifestation, according to previous threads 
> along the same lines).

i = (i + 3) + (i + 3) + (i + 3)
i = i + 3

> Or, are we not allowed to think or guess anything at all, simply because the 
> C standard says the original expression has undefined behaviour?

no. If the implementor decides to tell you what the behaviour is- and guarantees the behaviour then you might trust that. Some UB is commonly 
used, 
   unsigned *reg = (unsigned*)0x8010;
   *reg = 0x01;   // fire lasers  

but I can see no point in silly code like this threads

[toc] | [prev] | [next] | [standalone]

#22541

"BartC" <bc@freeuk.com> writes:

> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnipek8bri.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>>> On 6/21/2012 5:08 PM, BartC wrote:
>>>
>>>>> "Yogesh Yadav Pacheria" <yogeshpacheria@gmail.com> wrote in message
>
>>>>>>   int i = 0;
>>>>>>   i = ++i + ++i + ++i;
>>>>>>   printf("%d",i);
>>>
>>>>>> Output should be 6
>>>>>>
>>>>>> But In GCC it's 7
>>>
>>>>> I agree it ought to be 6.
>
>>> And once you know the result, would you gamble on the same compiler
>>> giving
>>> the exactly the same answer one more time?
>>
>> What would be the point?  Don't waste time guessing what the code might
>> do for a given implementation.  Just fix it.
>
> OK, so we fix it so that the result is ....? Any guesses?

Argh!  Another chasm opens up!  There can be no guess.  You fix it by
choosing what you want it to mean.  You choose it to mean 6, so you "fix
it" (in all senses of the word) by re-writing it as:

> Changing the erroneous code so that it stays within the rules:
>
> int i = 0;
> int t1,t2,t3;
>
> t1=++i;
> t2=++i;
> t3=++i;
> i=t1+t2+t3;
> printf("%d",i);
>
> Now gives a valid result. Which happens to coincide with the OP's
> expectations,

It doesn't just "happen" to coincide -- you forced it to.  You have a
view of what the code "really" means, but that's just one rather
arbitrary point of view.  To take another, ++i, when i is zero, sets i
to 1 and has the value one.  The statement

  i = ++i + ++i + ++i;

could, in this context, be taken to mean

  i = (i = 1) + (i = 1) + (i = 1);

which is still undefined of course but it looks quite different and your
expectation would probably be different.

The purpose of the sequence point rule (now gone) was to allow the
compiler to say "I know what value ++i has here, and I don't need to
change my mind about that until the next sequence point".

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.  But the other extreme -- we all know what
*should* happen, don't we? -- is equally unconvincing.  When the C
language does not define the meaning of a bit of code, something else
does, and that's enough for me.  I don't want to write code whose
meaning is in the hands of unknown entities.  This point of view covers
the much more significant case where I *know* what entity will define
the meaning of otherwise undefined code -- POSIX, for example.

> and with what I said it *ought* to be (for which I was
> called a 'nitwit', even though I went on to explain why the OP wasn't
> getting that result), and in fact with what most of my compilers were
> already giving me anyway; presumably they were already using code
> along the same lines!)
>
> However, the interesting question is, why anyone - outside c.l.c
> obviously - 
> might think the output of the OP's original code might be 6, rather
> than any other number (or any other manifestation, according to
> previous threads along the same lines).
>
> Or, are we not allowed to think or guess anything at all, simply
> because the C standard says the original expression has undefined
> behaviour?

Think and guess all you like, but it's disingenuous to suggest that's
all you were doing.  You said the value *ought* to be 6 and that's got
to be designed to get a more robust response, no?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#22549

Ben Bacarisse wrote:
<snip>
>
> Think and guess all you like, but it's disingenuous to suggest that's
> all you were doing.  You said the value *ought* to be 6 and that's got
> to be designed to get a more robust response, no?
>

Oy, "is-ought distinction" in c.l.c! To the tune of "anarchy in the UK"...

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#22656

On Friday, June 22, 2012 2:34:58 PM UTC+1, Ben Bacarisse wrote:
> "BartC" <bc@freeuk.com> writes:

<snip>

> 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. 

a poster on here used to claim he'd seen a system pop up the old DOS dialog box saying "Are You Sure You Want To Reformat C:?". For some sort of UB (not tricks with ++ but (I think) some sort of out of bounds thing).

> But the other extreme -- we all know what
> *should* happen, don't we? -- is equally unconvincing.  When the C
> language does not define the meaning of a bit of code, something else
> does, and that's enough for me.  I don't want to write code whose
> meaning is in the hands of unknown entities.  This point of view covers
> the much more significant case where I *know* what entity will define
> the meaning of otherwise undefined code -- POSIX, for example.

I've seen program behaviour change due to UB when a compiler was upgraded (same manufacturer). Changing optimisation can do it too.

<snip>

[toc] | [prev] | [next] | [standalone]

#22680

nick_keighley_nospam@hotmail.com writes:

> On Friday, June 22, 2012 2:34:58 PM UTC+1, Ben Bacarisse wrote:
>> "BartC" <bc@freeuk.com> writes:
>
> <snip>
>
>> 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. 
>
> a poster on here used to claim he'd seen a system pop up the old DOS
> dialog box saying "Are You Sure You Want To Reformat C:?". For some
> sort of UB (not tricks with ++ but (I think) some sort of out of
> bounds thing).

Exactly.  Even beginners soon realise that "anything can happen" is not
really true.  The truth should be scary enough.

>> But the other extreme -- we all know what
>> *should* happen, don't we? -- is equally unconvincing.  When the C
>> language does not define the meaning of a bit of code, something else
>> does, and that's enough for me.  I don't want to write code whose
>> meaning is in the hands of unknown entities.  This point of view covers
>> the much more significant case where I *know* what entity will define
>> the meaning of otherwise undefined code -- POSIX, for example.
>
> I've seen program behaviour change due to UB when a compiler was
> upgraded (same manufacturer). Changing optimisation can do it too.

Yup, or even just using different compiler options.  You want to be the
one defining what your programs mean, not leaving up to other entities
(unless you need to like in my POSIX example).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#22683

On 6/25/2012 3:27 AM, nick_keighley_nospam@hotmail.com wrote:
>[...]
> I've seen program behaviour change due to UB when a compiler was upgraded (same manufacturer). Changing optimisation can do it too.

     Even an "unrelated" change to the program can expose UB in
an unchanged section.  See also "Heisenbug."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#22690

On 6/25/2012 9:42 AM, Eric Sosman wrote:
> On 6/25/2012 3:27 AM, nick_keighley_nospam@hotmail.com wrote:
>> [...]
>> I've seen program behaviour change due to UB when a compiler was upgraded
>> (same manufacturer). Changing optimisation can do it too.
>
>      Even an "unrelated" change to the program can expose UB in
> an unchanged section.  See also "Heisenbug."

Yup.  I've had bugs that not only would behave differently within the 
debugger than without, I've also seen bugs that would behave differently 
within the debugger, depending on if you single-stepped through a few lines 
of code or stepped "over" them.  (By "stepped 'over'" I mean that the 
debugger executes the lines and then stops on the next statement, not that 
skips over the code.)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#23084

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.

[toc] | [prev] | [next] | [standalone]

#23085

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

[toc] | [prev] | [next] | [standalone]

#23087

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).

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web