Plz explain me the following code

[manish sahu]

plz tell me how this code is working and what would be the the o/p
1)

{
int x=20,y=35;
x = y++ + x++;
y = ++y + ++x;
printf("%d %dn",x,y);
}


2)
{
int x=5;
printf("%d %d %dn",x,x<<2,x>>2);
}
Thankyou

 

[Nick Keighley]

plz tell me how this code is working and what would be the the o/p
1)

{
int x=20,y=35;
x = y++ + x++;

the C standard does not define the behaviour of a program like
this. Anything like
i = i++;
exhibits undefined behaviour. Dig out the comp.lang.c FAQ for details

y = ++y + ++x;
printf("%d %dn",x,y);

}

2)
{
int x=5;
printf("%d %d %dn",x,x<<2,x>>2);}

why don't you just run the program? Look in your textbook
to find out what << and >> do

 

[Seebs]

plz tell me how this code is working and what would be the the o/p
1)

{
int x=20,y=35;
x = y++ + x++;
y = ++y + ++x;
printf("%d %dn",x,y);
}

This could do just about anything; it's undefined behavior and there is no
realistic way to determine what it "should" produce.

2)
{
int x=5;
printf("%d %d %dn",x,x<<2,x>>2);
}

This one is well-defined and requires no explanation.

-s

 

[manish sahu]

This could do just about anything; it's undefined behavior and there is no
realistic way to determine what it "should" produce.


This one is well-defined and requires no explanation.

-s

Thankyou dear

 

[Peter Nilsson]

This one is well-defined and requires no explanation.

Whether a text line requires a terminating new-line is
implementation defined. There can be practical consequences
to leaving it off. [e.g. on old line printers.]

 

[Ben Pfaff]

This one is well-defined and requires no explanation.

Whether a text line requires a terminating new-line is
implementation defined. There can be practical consequences
to leaving it off. [e.g. on old line printers.]

The "n" is there, I think that manish just left off the \ as a
typo.

 

[Keith Thompson]

This one is well-defined and requires no explanation.

Whether a text line requires a terminating new-line is
implementation defined. There can be practical consequences
to leaving it off. [e.g. on old line printers.]

"n" was almost certainly a typo for "\n".

It's not clear that the output produced by the printf call is going to
be the last line of the program's output. The posted code was just a
single compound statement. It was probably intended to be the body of
main(), but as long as we're not making assumptions ...

 

[Processor-Dev1l]

plz tell me how this code is working and what would be the the o/p
1)

{
int x=20,y=35;
x = y++ + x++;
y = ++y + ++x;
printf("%d %dn",x,y);

}

x is set to 20 and y is set to 35.
in the next line you make x a result of 20+35 and THEN you increase
both x and y. It means x should be 56 and y 35.
Then you increase x (57) and y (36) and y = y + x will make y to be
set to 93.
But as my colleagues here said, it is compiler dependent (this code
can be just junk)

2)
{
int x=5;
printf("%d %d %dn",x,x<<2,x>>2);}

Thankyou

Man, find out something about binary shifts by yourself .

 

[Processor-Dev1l]

x is set to 20 and y is set to 35.
in the next line you make x a result of 20+35 and THEN you increase
both x and y. It means x should be 56 and y 35.
Then you increase x (57) and y (36) and y = y + x will make y to be
set to 93.
But as my colleagues here said, it is compiler dependent (this code
can be just junk) Correction here:
x is set to 20 and y is set to 35.
in the next line you make x a result of 20+35 and THEN you increase
both x and y. It means x should be 56 and y 36.
Then you increase x (57) and y (37) and y = y + x will make y to be
set to 94.
But as my colleagues here said, it is compiler dependent (this code
can be just junk)




Man, find out something about binary shifts by yourself .

Sorry for typo...

 

[Keith Thompson]

x is set to 20 and y is set to 35.
in the next line you make x a result of 20+35 and THEN you increase
both x and y. It means x should be 56 and y 35.
Then you increase x (57) and y (36) and y = y + x will make y to be
set to 93.
But as my colleagues here said, it is compiler dependent (this code
can be just junk)

The behavior is undefined, as several posters have already pointed
out.

[snip]

 

[Processor-Dev1l]

x is set to 20 and y is set to 35.
in the next line you make x a result of 20+35 and THEN you increase
both x and y. It means x should be 56 and y 35.
Then you increase x (57) and y (36) and y = y + x will make y to be
set to 93.
But as my colleagues here said, it is compiler dependent (this code
can be just junk)

The behavior is undefined, as several posters have already pointed
out.

[snip]

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

I just did a test on mainframe....

$ cat ctest.c
#include <stdio.h>

int main(void)
{
int x;
int y;

x = 20;
y = 35;

x = y++ + x++;
y = ++y + ++x;
printf("x = %d, y = %d\n", x, y);

return 0;
}
$ cc ctest.c
IGD01008I ALLOCATION SET TO SCTEMPD M0610
IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
IGD01008I ALLOCATION SET TO SCTEMPD M0610
IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
$ ./a.out
x = 57, y = 94
$

Everything what I want is someone with linux to try it with gcc
compiler, that is
all.

 

[Nick Keighley]

The behavior is undefined, as several posters have already pointed
out.

[snip]

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

I just did a test on mainframe....

$ cat ctest.c
#include <stdio.h>

int main(void)
{
  int x;
  int y;

  x = 20;
  y = 35;

  x = y++ + x++;
  y = ++y + ++x;
  printf("x = %d, y = %d\n", x, y);

  return 0;}

$ cc ctest.c
IGD01008I ALLOCATION SET TO SCTEMPD M0610
IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
IGD01008I ALLOCATION SET TO SCTEMPD M0610
IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
$ ./a.out
x = 57, y = 94
$

Everything what I want is someone with linux to try it with gcc
compiler, that is
all.

why? It is Undefined Behaviour. Even changing the compiler
optimisation
level may change the result

 

[Processor-Dev1l]

plz tell me how this code is working and what would be the the o/p
1)
{
int x=20,y=35;
x = y++ + x++;
y = ++y + ++x;
printf("%d %dn",x,y);
}
x is set to 20 and y is set to 35.
in the next line you make x a result of 20+35 and THEN you increase
both x and y. It means x should be 56 and y 35.
Then you increase x (57) and y (36) and y = y + x will make y to be
set to 93.
But as my colleagues here said, it is compiler dependent (this code
can be just junk)
The behavior is undefined, as several posters have already pointed
out.
[snip]
--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

I just did a test on mainframe....

$ cat ctest.c
#include <stdio.h>

int main(void)
{
  int x;
  int y;

  x = 20;
  y = 35;

  x = y++ + x++;
  y = ++y + ++x;
  printf("x = %d, y = %d\n", x, y);

  return 0;}

$ cc ctest.c
IGD01008I ALLOCATION SET TO SCTEMPD M0610
IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
IGD01008I ALLOCATION SET TO SCTEMPD M0610
IGD01010I ALLOCATION SET TO SGTEMPD STORAGE GROUP
$ ./a.out
x = 57, y = 94
$

Everything what I want is someone with linux to try it with gcc
compiler, that is
all.

why? It is Undefined Behaviour. Even changing the compiler
optimisation
level may change the result

Why? Because it works on USS cc modified compiler and because I was
trained to code this way .
I would do the test myself, but I have no access to common linux
kernel now...

 

[Barry Schwarz]

x is set to 20 and y is set to 35.
in the next line you make x a result of 20+35 and THEN you increase
both x and y. It means x should be 56 and y 35.

There is no defined time when side effects will occur in relation to
other events within the current interval between sequence points. What
might be guaranteed is:
1 - x++ is evaluated (yielding 20).
2 - y++ is evaluated (yielding 35).
3 - At some point during or after the evaluation of x++, the
side effect of incrementing x occurs.
4 - At some point during or after the evaluation of y++, the
side effect of incrementing y occurs.
5 - At some point after both x++ and y++ are evaluated, the +
operand is evaluated (yielding 55).
6 - At some point after the + operand is evaluated, the sum is
stored in x.

The ordering of 1 and 2 is unspecified. 1 must occur before 3, 2
before 4, 1 and 2 before 5, and 5 before 6. Notice that there is no
relationship in the sequencing of 3, 4, and 6. In any sequence where
3 occurs before 6, x will end up containing 55. In any other
sequence, x may end up containing 21 (since the value being
incremented was determined to be 20) or may end up containing 56
(since the current value of x is 55).

Your subsequent test of a particular system proves nothing.

Then you increase x (57) and y (36) and y = y + x will make y to be
set to 93.

But you don't know which of three plausible values x contains at this
point. Since the behavior is explicitly undefined in the standard,
there are a lot of other values x could contain or this statement
might not even be executed.

 

[Seebs]

x is set to 20 and y is set to 35.
in the next line you make x a result of 20+35 and THEN you increase
both x and y. It means x should be 56 and y 35.
Wrong.

But as my colleagues here said, it is compiler dependent (this code
can be just junk)

Which is to say, the previous explanation is not correct, and has no meaning.

-s

 

[Seebs]

Why? Because it works on USS cc modified compiler and because I was
trained to code this way .

Trained to try experiments that you can easily prove are meaningless and
make proclamations about the results? That is a very strange way to be
trained to code.

-s

 

[Processor-Dev1l]

There is no defined time when side effects will occur in relation to
other events within the current interval between sequence points. What
might be guaranteed is:
        1 - x++ is evaluated (yielding 20).
        2 - y++ is evaluated (yielding 35).
        3 - At some point during or after the evaluation of x++, the
side effect of incrementing x occurs.
        4 - At some point during or after the evaluation of y++, the
side effect of incrementing y occurs.
        5 - At some point after both x++ and y++ are evaluated, the +
operand is evaluated (yielding 55).
        6 - At some point after the + operand is evaluated, the sum is
stored in x.

The ordering of 1 and 2 is unspecified.  1 must occur before 3, 2
before 4, 1 and 2 before 5, and 5 before 6.  Notice that there is no
relationship in the sequencing of 3, 4, and 6.  In any sequence where
3 occurs before 6, x will end up containing 55.  In any other
sequence, x may end up containing 21 (since the value being
incremented was determined to be 20) or may end up containing 56
(since the current value of x is 55).

Your subsequent test of a particular system proves nothing.


But you don't know which of three plausible values x contains at this
point.  Since the behavior is explicitly undefined in the standard,
there are a lot of other values x could contain or this statement
might not even be executed.

Congratz, yours was first acceptable answer .

Pitty is this style can be found even in some "ansi" C oriented books.
It's really a pitty because what is written should be right...

for manish:
It is always better to use x++ on a standalone line except "for" cycle.

 

[James Dow Allen]

plz tell me how this code is working ...
...
x = y++ + x++;

I have a sincere question for manish. And for the dozens of
others who've asked almost the same question lately.

Manish, why do you want to use this expression and, if
there's no good reason, why do you particularly care
what it does?

I ask because even non-experts who know a little C can
glance at the expression, realize that it at least *looks*
potentially ambiguous, and *realize that the whole expression
can easily be avoided*.

It's fun to explore the nooks and crannies of a programming
language, but why do so many beginners focus on the silly
and useless?

I'm reminded of a programmer (who didn't consider himself
a beginner!) who looked over my shoulder as I proudly
typed 'ls *.c' in my self-written image processing source
directory. I had an adaptive histogram equalizer, advanced
value-criterion filters and much more ... but he selected
only the silly (and sillily-named) "kluge.c" for perusal!

James

 

[Seebs]

Manish, why do you want to use this expression and, if
there's no good reason, why do you particularly care
what it does?

I suspect it's a desire to understand how things work.

It's fun to explore the nooks and crannies of a programming
language, but why do so many beginners focus on the silly
and useless?

Because edge conditions teach you more.

I'm reminded of a programmer (who didn't consider himself
a beginner!) who looked over my shoulder as I proudly
typed 'ls *.c' in my self-written image processing source
directory. I had an adaptive histogram equalizer, advanced
value-criterion filters and much more ... but he selected
only the silly (and sillily-named) "kluge.c" for perusal!

That would be the most interesting to me, too! That would be the one
that showed me where you had interesting things happening that you weren't
quite sure about, probably.

An adaptive histogram equalizer is probably boring. The curious hack
you adopted because something was acting weird is probably interesting.

-s

 

[Processor-Dev1l]

Wrong.

Nice you are quoting my typo .
There is also a post where I repaired it .
You can also take a look at my test where I compiled and ran that
code.
If all you can do is to quote wrong post and to say only Wrong, you
are just jerk .

Another thing that makes me thinking you are jerk is that you are
posting into already answered topic (greatly answered by Barry).

Which is to say, the previous explanation is not correct, and has no meaning.

It is not correct, it is compiler dependent, that is the
difference .

I know maybe you will not understand if you have ever tried just one
compiler or you are thinking that all C compilers are from God and all
are the same with same parsing, etc.
My tested compiler was capable of such operations, but I have never
said it is a standard (Maybe some C999 will mention it).
Counting I used is a common counting for High Level Languages, these
are capable to parse such operations, I also tested the code on
machine and the result supported my idea, but I still never said it is
a standard.


So let's summarize it:
Is it possible for the code to work as I said? Yes, it is possible,
but it depends on the compiler
Is it standard for the code to work as I said? No, it is not!