to guru : strange C++ operator behaviour

[Dmitriy Iassenev]

hi,

I found an interesting thing in operator behaviour in C++ :

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

I think the value of the expression "i++ + i++" _must_ be 3, but all the
compilers I tested print 2.

Then I tried another example

std::vector<int > a;
a.push_back(1);
a.push_back(2);
std::vector<int >::iterator i = a.begin();
printf("%d",*i+ + + *i++);

Different compilers print different values : 2 or 3, thought it _must_ be 3.

Possibly, it is because of the compilers C compatibility, since iterators
are C++ construction and their behaviour therefore suits C++ standards,
while for the basic types compilers guarantee C behaviour.

Bjarne Stroustrup wrote in his book that
y = ++x; is equivalent to y = (x+=1);
while
y = x++; is equivalent to y = (t=x,x+=1,t);

Why do all the compilers incorrectly compute the expressions?

Many thanks in advance,
Dmitriy Iassenev.

[tom_usenet]

Re: to guru : strange C++ operator behaviour

On Thu, 2 Oct 2003 19:55:37 +0300, "Dmitriy Iassenev"
<iassenev@gsc-game.kiev.ua> wrote:
[color=blue]
>hi,
>
>I found an interesting thing in operator behaviour in C++ :
>
>int i=1;
>printf("%d",i+ + + i++);
>
>I think the value of the expression "i++ + i++" _must_ be 3, but all the
>compilers I tested print 2.[/color]

This is an FAQ:

http://www.eskimo.com/~scs/C-faq/s3.html

Tom

[WW]

Re: to guru : strange C++ operator behaviour

Dmitriy Iassenev wrote:[color=blue]
> hi,
>
> I found an interesting thing in operator behaviour in C++ :
>
> int i=1;
> printf("%d",i++ + i++);
>
> I think the value of the expression "i++ + i++" _must_ be 3, but all
> the compilers I tested print 2.[/color]

You think wrong. The above is undefined behavior. You try to change the
value of a variable more than once with an intervening sequence point. The
compiler is allowed to do whatever it wants, including formatting your
harddisk. Search for sequence point i+++++i on Google. One page is:

http://www.embedded.com/story/OEG20020625S0041

--
WW aka Attila

[Howard]

Re: to guru : strange C++ operator behaviour

[color=blue]
>
> int i=1;
> printf("%d",i++ + i++);
>
> I think the value of the expression "i++ + i++" _must_ be 3, but all the
> compilers I tested print 2.
>[/color]
[color=blue]
>
> Bjarne Stroustrup wrote in his book that
> y = ++x; is equivalent to y = (x+=1);
> while
> y = x++; is equivalent to y = (t=x,x+=1,t);
>
> Why do all the compilers incorrectly compute the expressions?
>[/color]

His statement agrees with your test perfectly, doesn't it? You get back 2,
which is 1+1, and after that value is computed, then i gets incremented
(twice). Using his notation,

y = x++ + x++; would be like

y = (t = x+x, x+=1, x+= 1, t);

Right?

-Howard

[Howard]

Re: to guru : strange C++ operator behaviour


[color=blue]
> You think wrong. The above is undefined behavior. You try to change the
> value of a variable more than once with an intervening sequence point.[/color]
The[color=blue]
> compiler is allowed to do whatever it wants, including formatting your
> harddisk. Search for sequence point i+++++i on Google. One page is:
>[/color]

Oh, good point. I forgot about sequence points.

But regardless of what "undefined behavior" means in the standard, you had
best not sell me a compiler that formats my hard drive if I screw up simple
code like this...I know a good lawyer! :-)

-Howard

[Fao, Sean]

Re: to guru : strange C++ operator behaviour


"Howard" <alicebt@hotmai l.com> wrote in message
news:blhlml$qoq @dispatch.conce ntric.net...[color=blue]
>[color=green]
> >
> > int i=1;
> > printf("%d",i++ + i++);
> >
> > I think the value of the expression "i++ + i++" _must_ be 3, but all the
> > compilers I tested print 2.
> >[/color]
>[color=green]
> >
> > Bjarne Stroustrup wrote in his book that
> > y = ++x; is equivalent to y = (x+=1);
> > while
> > y = x++; is equivalent to y = (t=x,x+=1,t);
> >
> > Why do all the compilers incorrectly compute the expressions?
> >[/color]
>
> His statement agrees with your test perfectly, doesn't it? You get back[/color]
2,[color=blue]
> which is 1+1, and after that value is computed, then i gets incremented
> (twice). Using his notation,
>
> y = x++ + x++; would be like
>
> y = (t = x+x, x+=1, x+= 1, t);
>
> Right?[/color]

Wrong. modifying the same variable twice in the same expression in
undefined so anything could happen.

[Fao, Sean]

Re: to guru : strange C++ operator behaviour

"Dmitriy Iassenev" <iassenev@gsc-game.kiev.ua> wrote in message
news:blhl7k$8ht $1@news.lucky.n et...[color=blue]
> hi,
>
> I found an interesting thing in operator behaviour in C++ :
>
> int i=1;
> printf("%d",i++ + i++);[/color]

http://www.eskimo.com/~scs/C-faq/q3.3.html

[Victor Bazarov]

Re: to guru : strange C++ operator behaviour

"Howard" <alicebt@hotmai l.com> wrote...[color=blue]
>[color=green]
> >
> > int i=1;
> > printf("%d",i++ + i++);
> >
> > I think the value of the expression "i++ + i++" _must_ be 3, but all the
> > compilers I tested print 2.
> >[/color]
>[color=green]
> >
> > Bjarne Stroustrup wrote in his book that
> > y = ++x; is equivalent to y = (x+=1);
> > while
> > y = x++; is equivalent to y = (t=x,x+=1,t);
> >
> > Why do all the compilers incorrectly compute the expressions?
> >[/color]
>
> His statement agrees with your test perfectly, doesn't it? You get back[/color]
2,[color=blue]
> which is 1+1, and after that value is computed, then i gets incremented
> (twice). Using his notation,
>
> y = x++ + x++; would be like
>
> y = (t = x+x, x+=1, x+= 1, t);
>
> Right?[/color]

Nope. Modifying a value of an object twice between sequence points
causes undefined behaviour. Anything is allowed to happen.

The expression (x++ + x++) is NOT like (t = x+x, x+=2) because there
is NO sequence point in the former, whereas in the latter there is
one at the comma.

Victor

[Dmitriy Iassenev]

Re: to guru : strange C++ operator behaviour

Many thanks to all of you,

I did find an answer in the FAQ that clarified the described situation.

Best regards,
Dmitriy Iassenev.

[Mike Wahler]

Re: to guru : strange C++ operator behaviour


"Howard" <alicebt@hotmai l.com> wrote in message
news:blhlt1$qot @dispatch.conce ntric.net...[color=blue]
>
>[color=green]
> > You think wrong. The above is undefined behavior. You try to change[/color][/color]
the[color=blue][color=green]
> > value of a variable more than once with an intervening sequence point.[/color]
> The[color=green]
> > compiler is allowed to do whatever it wants, including formatting your
> > harddisk. Search for sequence point i+++++i on Google. One page is:
> >[/color]
>
> Oh, good point. I forgot about sequence points.
>
> But regardless of what "undefined behavior" means in the standard, you had
> best not sell me a compiler that formats my hard drive if I screw up[/color]
simple[color=blue]
> code like this...I know a good lawyer! :-)[/color]

So if I sell you a chain saw, and due to your ignorance
you cut off your hand, you'll sue me? I suppose so.
Only in America. :-)

-Mike

[WW]

Re: to guru : strange C++ operator behaviour

Howard wrote:[color=blue][color=green]
>> You think wrong. The above is undefined behavior. You try to
>> change the value of a variable more than once with an intervening
>> sequence point. The compiler is allowed to do whatever it wants,
>> including formatting your harddisk. Search for sequence point
>> i+++++i on Google. One page is:
>>[/color]
>
> Oh, good point. I forgot about sequence points.
>
> But regardless of what "undefined behavior" means in the standard,
> you had best not sell me a compiler that formats my hard drive if I
> screw up simple code like this...I know a good lawyer! :-)[/color]

That is outside of the topic of this newsgroup. It belongs to QoI (Quality
of Implementation) . ;-)

--
WW aka Attila

[WW]

Re: to guru : strange C++ operator behaviour

Fao, Sean wrote:[color=blue]
> Wrong. modifying the same variable twice in the same expression in
> undefined so anything could happen.[/color]

Yeah. Last time I have tried I have laid an egg and a politician told the
truth on national TV. ;-)

--
WW aka Attila

[Mark Kerns]

Re: to guru : strange C++ operator behaviour

> So if I sell you a chain saw, and due to your ignorance[color=blue]
> you cut off your hand, you'll sue me?[/color]

Of course. First I'd sue you, pay my lawyer, declare bankruptcy, and avoid
your counter-suit. This is America after all.

[Howard]

[OT] Re: to guru : strange C++ operator behaviour


"Mike Wahler" <mkwahler@mkwah ler.net> wrote in message
news:AlZeb.1121 7$RW4.3023@news read4.news.pas. earthlink.net.. .[color=blue]
>
> "Howard" <alicebt@hotmai l.com> wrote in message
> news:blhlt1$qot @dispatch.conce ntric.net...[color=green]
> >[/color]
>[color=green]
> > But regardless of what "undefined behavior" means in the standard, you[/color][/color]
had[color=blue][color=green]
> > best not sell me a compiler that formats my hard drive if I screw up[/color]
> simple[color=green]
> > code like this...I know a good lawyer! :-)[/color]
>
> So if I sell you a chain saw, and due to your ignorance
> you cut off your hand, you'll sue me? I suppose so.
> Only in America. :-)
>
> -Mike
>[/color]

:-)

Funny, but a bit ludicrous, Mike. If I buy a chain saw, I know it has the
capability to cut off my hand (or anything else) if I abuse it. After all,
it is DESIGNED to cut things off! However, writing a compiler that
translates the standard's meaing of "undefined behavior" into "I can format
his hard drive if I want" is an act of malice, or at least negligence, and
would definitely be actionable in a court of law (and probably not just in
the US either). Do you write programs that, if the user does not read and
understand your user's manual correctly, will format their hard drive? If
so, please let me know what products you produce so I can avoid them! :-)

As a side note, the reason I brought this up is that that statement about
formatting someone's hard drive when undefined behavior is invoked is used
quite often in this newsgroup, but is, in my opinion, very misleading. The
standard may state that a specific type of coding constitutes undefined
behavior under the standard, but that does NOT mean anyone actually writes
compilers that take malicious or bizarre actions under those circumstances.
Compiler writers have customers that must be satisfied, and some (if not
all) of those customers are BOUND to make mistakes sometimes. It is an
imperative that they take at least "reasonable " actions when undefined
behavior is encountered (assuming that they understand and can detect those
conditions in the first place). Failure to do so will lose them customers,
and money, FAST! (Now, if there are any compiler WRITERS out there that
disagree, please let us know. :-))

How about, when telling posters about the meaning of "undefined behavior",
we leave it at that, and don't insinuate (or outright state) that they're
going to lose their hard drive if they make a mistake, ok?

-Howard





[color=blue]
>[/color]

[Kevin Goodsell]

Re: [OT] Re: to guru : strange C++ operator behaviour

Howard wrote:
[color=blue]
> Funny, but a bit ludicrous, Mike. If I buy a chain saw, I know it has the
> capability to cut off my hand (or anything else) if I abuse it. After all,
> it is DESIGNED to cut things off! However, writing a compiler that
> translates the standard's meaing of "undefined behavior" into "I can format
> his hard drive if I want" is an act of malice, or at least negligence,[/color]

What you apparently fail to realize is that the compiler *cannot* detect
undefined behavior in general, and thus cannot assign behavior to it,
nor can a compiler control what happens in the computer system when a
program attempts to do something it shouldn't. Consider DOS systems with
no memory protection. What happens if you overwrite a random memory area
with a random value? Just about anything is possible, as with undefined
behavior in general.

According to Richard Heathfield in _C Unleashed_, page 68-69:

Nasal Demons

The two most dramatic results of undefined behavior I have personally
witnessed both involved leaving insufficient room in a char array for
the terminating null character of a string.

The first occasion was in 1989, and the victim was my brother, Steve. He
(ahem) drew my attention to his screen, which was displaying a message
asking him to confirm that he wanted to format his hard disk. He was
lucky -- he was asked.

A year or so later, a colleague of mine (hi, Kevin) wasn't quite so
lucky. The first sign of his program's undefined behavior was that his
machine hung. The second sign was that it wouldn't reboot! He had to
spend quite some time nursing the machine back to health using the
diagnostic floppies supplied by the manufacturer.

I've never had anything that bad happen to me. In a way, I've been
fortunate. I would love to bring you a really embarrassing first-hand
account of how I brought down a major government by dereferencing a NULL
pointer or flooded a city by passing (UCHAR_MAX + 1) to isupper(). My
own bugs have been far less dramatic. Sorry to disappoint you.

<snip>
[color=blue]
>
> As a side note, the reason I brought this up is that that statement about
> formatting someone's hard drive when undefined behavior is invoked is used
> quite often in this newsgroup, but is, in my opinion, very misleading.[/color]

It's not even remotely misleading. According to the standard it is
perfectly possible and permissible. Real life is off-topic here (but
note, from the quote above, that this *does* happen in real life).
[color=blue]
> The
> standard may state that a specific type of coding constitutes undefined
> behavior under the standard, but that does NOT mean anyone actually writes
> compilers that take malicious or bizarre actions under those circumstances.[/color]

Never was the claim.
[color=blue]
> Compiler writers have customers that must be satisfied, and some (if not
> all) of those customers are BOUND to make mistakes sometimes. It is an
> imperative that they take at least "reasonable " actions when undefined
> behavior is encountered (assuming that they understand and can detect those
> conditions in the first place).[/color]

Which they cannot.
[color=blue]
> Failure to do so will lose them customers,
> and money, FAST! (Now, if there are any compiler WRITERS out there that
> disagree, please let us know. :-))
>
> How about, when telling posters about the meaning of "undefined behavior",
> we leave it at that, and don't insinuate (or outright state) that they're
> going to lose their hard drive if they make a mistake, ok?[/color]

They could. We shouldn't warn them? They're free to weigh the risk
themselves.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.