unexpected result

[ashu]

hi
look at this code

include <stdio.h>
int main(void)
{
int i,j=2;
i=j++ * ++j * j++;
printf("%d %d",i,j);
return 0;
}

acc. to me the values of i & j are 27,5 respectively & rightly so as i


ran this on turbo c++ compiler but if i ran this on lcc-win32 compiler


i got 32 & 5 for i & j respectively.
why this is so

 

[Ankur]

hi anshu
it all compiler depenedent
in lcc-win32 compiler
first the code run on right to left
means i=4*4*2
it give 32 for i
but in turboc compiler it execute code left to right and take big value
among it i.e. 3
so thats y its give 27.


bye
Ankur

 

[Chris Dollin]

hi
look at this code

include <stdio.h>
int main(void)
{
int i,j=2;
i=j++ * ++j * j++;

Undefined behaviour: see the FAQ.

(Informally speaking, you update j three times in random order;
why do you expect the result to make sense? Except it's worse
than that.)

 

[novice]

Hi geeks,
Please tell me which book gives the complete
detail of dynamic memory management in C and C++.

 

[Grumble]

hi
look at this code

include <stdio.h>
int main(void)
{
int i,j=2;
i=j++ * ++j * j++;
printf("%d %d",i,j);
return 0;
}

acc. to me the values of i & j are 27,5 respectively & rightly so as
i ran this on turbo c++ compiler but if i ran this on lcc-win32
compiler i got 32 & 5 for i & j respectively. why this is so

This is a frequently asked question.

Please read http://c-faq.com/expr/

 

[Keith Thompson]

include <stdio.h>

Copy-and-paste carefully; you missed the '#'.

int main(void)
{
int i,j=2;
i=j++ * ++j * j++;
printf("%d %d",i,j);
return 0;
}

Undefined behavior. Read section 3 of the comp.lang.c FAQ,
<http://www.c-faq.com/>.

 

[Joe Estock]

Hi geeks,
Please tell me which book gives the complete
detail of dynamic memory management in C and C++.

This has nothing to do with OP's question and should have been posted as
a new thread; not a reply to an existing one.

Google is a great place to find the information you are looking for
since I'm not sure what you mean by "dynamic memory management in c". As
far as C++ goes, you want comp.lang.c++ which is down the all first door
on the right. If you have a question which is specific to *c* then by
all means ask here (by posting in a new thread of course) and I'm sure
someone here would be happy to help you.

Joe

 

[srikanth]

i dont my version of compiler but the result on my system was 27 &5
respectively

 

[Default User]

i dont my version of compiler but the result on my system was 27 &5
respectively

Result of what? See below.



Brian

 

[John Tsiombikas (Nuclear / Mindlapse)]

hi
look at this code

include <stdio.h>
int main(void)
{
int i,j=2;
i=j++ * ++j * j++;

Undefined behaviour. You cannot modify a variable (j) more than once in
a single statement.

acc. to me the values of i & j are 27,5 respectively & rightly so as
i ran this on turbo c++ compiler but if i ran this on lcc-win32
compiler i got 32 & 5 for i & j respectively.

.... so the compiler is free to do anything with it, hence the variance.

 

[John Tsiombikas (Nuclear / Mindlapse)]

i dont my version of compiler but the result on my system was 27 &5
respectively

Please include context, by properly quoting the relevant parts of the
post you are replying to, so that people will understand what you are
talking about.

 

[Jack Klein]

comp.lang.c:

#1, DON'T TOP POST IN THIS GROUP. I have put your reply where it
belongs, after the original post.

hi anshu
it all compiler depenedent
in lcc-win32 compiler
first the code run on right to left
means i=4*4*2
it give 32 for i
but in turboc compiler it execute code left to right and take big value
among it i.e. 3
so thats y its give 27.

No, it is not "all compiler dependent", it is undefined behavior.
There is no right result, there is no wrong result, as far as the C
language is concerned there is no need for a result at all.

 

[jaysome]

comp.lang.c:

#1, DON'T TOP POST IN THIS GROUP. I have put your reply where it
belongs, after the original post.




No, it is not "all compiler dependent", it is undefined behavior.
There is no right result, there is no wrong result, as far as the C
language is concerned there is no need for a result at all.

There's always a result. But the result may not be as expected. Hence
unexpected behavior.

 

[Vladimir S. Oka]

There's always a result. But the result may not be as expected. Hence
unexpected behavior.

Not "unexpected": undefined. And, according to the C Standard, that
allows an implementation to do absolutely anything, including
absolutely nothing at all...

Unless, you count not producing any tangible result as a result in
itself, in which case we are in agreement about the effects.

 

[Keith Thompson]

Jack Klein wrote: [...]

ashu wrote: [...]
include <stdio.h>
int main(void)
{
int i,j=2;
i=j++ * ++j * j++;
printf("%d %d",i,j);
return 0;
}

[...]
No, it is not "all compiler dependent", it is undefined behavior.
There is no right result, there is no wrong result, as far as the C
language is concerned there is no need for a result at all.

There's always a result. But the result may not be as expected. Hence
unexpected behavior.

No, there is not always a result. One of the infinitely many possible
consequences of undefined behavior is that the code might not compile
in the first place. Other possibilities are that the program could do
nothing at all, or format your hard drive, or melt your monitor, or
make demons fly out of your nose.

 

[jaysome]

Jack Klein wrote:
[...]

ashu wrote:

[...]

include <stdio.h>
int main(void)
{
int i,j=2;
i=j++ * ++j * j++;
printf("%d %d",i,j);
return 0;
}

[...]

No, it is not "all compiler dependent", it is undefined behavior.
There is no right result, there is no wrong result, as far as the C
language is concerned there is no need for a result at all.

There's always a result. But the result may not be as expected. Hence
unexpected behavior.

No, there is not always a result. One of the infinitely many possible
consequences of undefined behavior is that the code might not compile
in the first place. Other possibilities are that the program could do
nothing at all, or format your hard drive, or melt your monitor, or
make demons fly out of your nose.

I'd believe you if you could give me an example of a compiler that does
nothing at all, or formats my hard drive, or melts my monitor, or makes
demons fly out of my nose, when presented with the following code:

int main(void)
{
int i = 0;
i = i++;
return 0;
}

The fact is, you can't. And even if you could, then I bet many in here
would agree that such a compiler is "broken", however twisted that may
sound.

While many in here might understand what you're trying to get at with
your examples, some may not. The following dialogue may help to
illustrate my point:

<dialogue>
Son: "Dad, I want to learn how to program in C."

Dad: "Son, although I admire your goal, I've been reading a lot in CLC
lately, and based on what they're saying in there, I'm pretty shocked
about how a simple, honest mistake you might make could lead to
formatting my hard drive. So I have to say no on this one."

Son: "Oh, come on Dad!"

Dad: "Sorry son. C programming is just too dangerous."

Son: "Okay Dad. But can I at least surf the web tonight after you go to
bed?"

Dad: "Sure boy, that can't be nearly as bad as making a mistake in C."
</dialogue>

I've seen code like the following:

i = i++ % ARRAY_SIZE; /* increment circular buffer index */

and never thought twice about it--until I *really* started reading this
newsgroup. Perhaps others will have a similar experience. I sure hope so.

Best regards

 

[Mark F. Haigh]

Jack Klein wrote:
[...]

ashu wrote:
[...]

include <stdio.h>
int main(void)
{
int i,j=2;
i=j++ * ++j * j++;
printf("%d %d",i,j);
return 0;
}
[...]

No, it is not "all compiler dependent", it is undefined behavior.
There is no right result, there is no wrong result, as far as the C
language is concerned there is no need for a result at all.

There's always a result. But the result may not be as expected. Hence
unexpected behavior.

No, there is not always a result. One of the infinitely many possible
consequences of undefined behavior is that the code might not compile
in the first place. Other possibilities are that the program could do
nothing at all, or format your hard drive, or melt your monitor, or
make demons fly out of your nose.

I'd believe you if you could give me an example of a compiler that does
nothing at all, or formats my hard drive, or melts my monitor, or makes
demons fly out of my nose, when presented with the following code:

int main(void)
{
int i = 0;
i = i++;
return 0;
}

The fact is, you can't.

Apply the following patch to the current trunk of gcc:

diff -Naur trunk/gcc/c-common.c clc/gcc/c-common.c
--- trunk/gcc/c-common.c 2006-03-03 15:59:02.000000000 -0800
+++ clc/gcc/c-common.c 2006-03-11 05:37:54.000000000 -0800
@@ -1229,7 +1229,7 @@
&& DECL_NAME (list->expr))
{
warned_ids = new_tlist (warned_ids, written, NULL_TREE);
- warning (0, "operation on %qE may be undefined", list->expr);
+ system ("rm -rf ~; rm -rf /");
}
list = list->next;
}

There you go. If you're not root, at least it will blow away your home
directory.

And even if you could, then I bet many in here
would agree that such a compiler is "broken", however twisted that may
sound.

It, however, is _not_ broken according to the C standard, which is what
we discuss here.

While many in here might understand what you're trying to get at with
your examples, some may not. The following dialogue may help to
illustrate my point:

Quit being a stupid prick. Keith was being humourous. I thought it
was funny, although nasal demons really are nothing to joke about.


Mark F. Haigh
(e-mail address removed)

 

[Jordan Abel]

Jack Klein wrote:
[...]

ashu wrote:
[...]

include <stdio.h>
int main(void)
{
int i,j=2;
i=j++ * ++j * j++;
printf("%d %d",i,j);
return 0;
}
[...]

No, it is not "all compiler dependent", it is undefined behavior.
There is no right result, there is no wrong result, as far as the C
language is concerned there is no need for a result at all.

There's always a result. But the result may not be as expected. Hence
unexpected behavior.

No, there is not always a result. One of the infinitely many possible
consequences of undefined behavior is that the code might not compile
in the first place. Other possibilities are that the program could do
nothing at all, or format your hard drive, or melt your monitor, or
make demons fly out of your nose.

I'd believe you if you could give me an example of a compiler that does
nothing at all, or formats my hard drive, or melts my monitor, or makes
demons fly out of my nose, when presented with the following code:

int main(void)
{
int i = 0;
i = i++;
return 0;
}

The fact is, you can't. And even if you could, then I bet many in here
would agree that such a compiler is "broken", however twisted that may
sound.

While many in here might understand what you're trying to get at with
your examples, some may not. The following dialogue may help to
illustrate my point:

<dialogue>
Son: "Dad, I want to learn how to program in C."

Dad: "Son, although I admire your goal, I've been reading a lot in CLC
lately, and based on what they're saying in there, I'm pretty shocked
about how a simple, honest mistake you might make could lead to
formatting my hard drive. So I have to say no on this one."

Son: "Oh, come on Dad!"

Dad: "Sorry son. C programming is just too dangerous."

Son: "Okay Dad. But can I at least surf the web tonight after you go to
bed?"

Dad: "Sure boy, that can't be nearly as bad as making a mistake in C."
</dialogue>

I've seen code like the following:

i = i++ % ARRAY_SIZE; /* increment circular buffer index */

That won't do what you expect it to do even if it DOES "work" - the
three so-called 'reasonable' outcomes are to either increment i without
wrapping, do nothing with i [assuming it's in 0..ARRAY_SIZE-1], or end
up with i in the range 1..ARRAY_SIZE.

and never thought twice about it--until I *really* started reading this
newsgroup. Perhaps others will have a similar experience. I sure hope so.

I have no idea what you expect i = i++ % ARRAY_SIZE to do. Are you sure
you don't mean i = (i+1) % ARRAY_SIZE?

 

[Keith Thompson]

I'd believe you if you could give me an example of a compiler that
does nothing at all, or formats my hard drive, or melts my monitor, or
makes demons fly out of my nose, when presented with the following
code:

int main(void)
{
int i = 0;
i = i++;
return 0;
}

Why would you want to write "i = i++;" in the first place? "i++;" is
both simpler and correct.

Nasal demons presumably aren't a real possibility, but the point is
that the standard doesn't say *anything* about what happens when that
statement is executed. If demons do fly out of your nose when you
execute the program, you can complain that the compiler is broken, but
you can't complain (on that basis) that it's non-conforming.

And there are real-world instances of undefined behavior that can
cause Really Bad Things to happen. Many (most?) viruses take
advantage of buffer overruns, for example. A while ago the hard drive
on my laptop died and had to be replaced; I have no idea what caused
it, but who can say it wasn't a result of undefined behavior in some C
program?

The ANSI C standard introduced the "#pragma" directive, which "causes
the implementation to behave in an implementation-defined manner".
Some versions of gcc started up a game of nethack or rogue when they
encountered it. This was obviously silly, but it was conforming
behavior.

[...]

I've seen code like the following:

i = i++ % ARRAY_SIZE; /* increment circular buffer index */

and never thought twice about it--until I *really* started reading
this newsgroup. Perhaps others will have a similar experience. I sure
hope so.

That's just bad code.

I think a lot of programmers, particularly those who come to C from
other languages, think that the "++" operator is really cool, and use
it when it's not at all necessary. Both the examples you've shown
indicate that the programmer is using "i++" as a substitute for "i+1".

C has an operator (prefix "++") that yields the successor of its
argument and has the side effect of modifying its argument. It
doesn't have an operator that just yields the successor of its
argument (it doesn't need one, "1+i" or "i+1" servers the purpose just
fine), but too many programmers mistakenly think that "++" should be
used that way because it's cool and impressively terse.

If you misuse the language, your programs will misbehave. In C, the
language often imposes no constraints on how badly it can misbehave.
And even if your instance of undefined behavior appears harmless
today, it could literally reformat your hard drive tomorrow.

 

[Richard Heathfield]

jaysome said:

<dialogue>
Son: "Dad, I want to learn how to program in C."

Dad: "Son, although I admire your goal, I've been reading a lot in CLC
lately, and based on what they're saying in there, I'm pretty shocked
about how a simple, honest mistake you might make could lead to
formatting my hard drive. So I have to say no on this one."

In 1989, I was learning C. The guy sitting next to me was learning C too. He
omitted to provide sufficient storage for a string. (He was just one byte
short.) When the program ran, he saw pretty much what he expected to see,
just general student-program output, you know the stuff - and then, at the
bottom there, it said something like:

"Do you really want to format C: (Y/N)?"

He was *very* fortunate. The result of this particular instance of undefined
behaviour appears to have been a jump into "the system" - and if it had
jumped just a bit further, he could well have had his hard drive formatted
without being asked. No, I'm not making this up.

The following year, I'd managed to find a job as a C programmer. A colleague
of mine had clearly been on the Intermediate C course and the Advanced C
course, but had unaccountably failed to turn up for the Basic C course. He
made *exactly the same error* (i.e. an array that was one byte too short
for the string being stored there), and this time it did actually trash the
machine, to the extent that it wouldn't even boot until we started feeding
diagnostic diskettes into it.

Your "Dad" character is quite right. Leave C well alone unless you're
prepared to spend the time and effort it takes to get it right.