Is this correct..??

[jt]

#include <stdio.h>
void f();

int main()
{
long int i;
i=20;
f();
i = 10;
printf ("\n%d\n",i) ;
return 0;
}

void f()
{
int j=20;
*(&j+2)+=7;
}

I found this question in the internet. The output is 20. Even I didn’t
believe this till I executed this program.
The probable explanation will be:

&j refers to the address of j.
&j + 2 refers to the address next to j(since j is of type <int).
This may be place where the return address is stored.(i think the
return address is stored immediately after the variables).

That value is incremented by 7.
May be the assignment statement takes 7 bytes to be represented in the
macine language.
Therefore the assignment statement in the main(),<i=10wil l be
skipped.
So the value of "i" is never altered.


Is my explanation correct..??

[Ian Collins]

Re: Is this correct..??

jt wrote:

#include <stdio.h>
void f();
>
int main()
{
long int i;
i=20;
f();
i = 10;
printf ("\n%d\n",i) ;
return 0;
}
>
void f()
{
int j=20;
*(&j+2)+=7;
}
>
I found this question in the internet. The output is 20.

The result is undefined. On my box, it is

Segmentation Fault (core dumped)

--
Ian Collins.

[Richard Heathfield]

Re: Is this correct..??

jt said:

#include <stdio.h>
void f();
>
int main()
{
long int i;
i=20;
f();
i = 10;
printf ("\n%d\n",i) ;
return 0;
}
>
void f()
{
int j=20;
*(&j+2)+=7;
}
>
I found this question in the internet. The output is 20. Even I didn?t
believe this till I executed this program.

You shouldn't have believed it then, either. &j is okay, but adding 2 to it
yields an invalid pointer value, and that means that the behaviour of the
program is undefined. The behaviour you observed is only one of a
brazillion possible outcomes.

<snip>

Is my explanation correct..??

I didn't read it. *The* correct explanation is that the program is broken
in a way that places no constraints on the output. Explaining one
arbitrary output doesn't actually explain the bug, and therefore can't
explain the program.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Re: Is this correct..??

jt wrote:

#include <stdio.h>
void f();
>
int main()
{
long int i;
i=20;
f();
i = 10;
printf ("\n%d\n",i) ;
return 0;
}
>
void f()
{
int j=20;
*(&j+2)+=7;
}
>
I found this question in the internet. The output is 20. Even I didn?t
believe this till I executed this program.
The probable explanation will be:

We recently had another post whose code is broken in a similar manner.
These tricks seem very cute, but the code exhibits undefined behaviour,
which means that any result is possible.

&j refers to the address of j.

Correct.

&j + 2 refers to the address next to j(since j is of type <int).

No. It is an address that is sizeof &j + 2 bytes past the address &j.
It's an invalid pointer value since it points at no legal object at
all. The address &j is legal because it points to j. The address &j+1
is legal, but may not be deferenced (This is a general rule in C: that
you may legally point to one element past an array but may not use that
address in a lvalue context), but the address &j+2 is completely
invalid. Even forming it invokes implementation defined behaviour, let
alone deferencing it.

This may be place where the return address is stored.(i think the
return address is stored immediately after the variables).

Pure speculation. On some machines the return address is stored on a
separate stack. Other systems it may or may not be stored at the
address that this program expects it to be.

If you want to do tricks like this then assembler is far better than C.
Almost everthing is defined in assembler. Once you know the platform's
assembler and the type of object code that your compiler generates,
then you might be in a position to translate your tricks into C without
hoping for the favour of the Gods of undefined behaviour.

That value is incremented by 7.

What if one some platform int is 16 bits while function return addresses
are 32 bits? Another potential problem.

May be the assignment statement takes 7 bytes to be represented in the
macine language.

Pure speculation. Easily defeated by compiler optimisations. What if
your friendly optimisng compiler observes that i is used only ever by
printf and that the first assignment to i is never used and decides to
emit a printf statement like this:

printf("\n%d\n" , 10L);

Observe that there is a printf format specifier mismatch in your
original code: another invocation of undefined behaviour.

Therefore the assignment statement in the main(),<i=10wil l be
skipped.
So the value of "i" is never altered.
>
>
Is my explanation correct..??

No. Your explanation is the purest of unfounded speculation one can
imagine. Your program is broken and the fact that it appears to do
something cute on one particular platform, under one particular
compiler, and under one set of compiler options doesn't mean that
anything meaningful is guaranteed in any other circumstance.

If you want to learn machine level architecture then I suggest that an
assembly language course is actually better than messing around with
highly non-portable C code. You can always come back to C with a new
understanding of how things work behind the scenes and be more
confident of exactly what happens when programs like these are run than
just speculating.

[Barry Schwarz]

Re: Is this correct..??

On Sat, 26 Apr 2008 21:20:40 -0700 (PDT), jt <karthiks.840@g mail.com>
wrote:

>#include <stdio.h>
>void f();
>
>int main()
>{
long int i;
i=20;
f();
i = 10;
printf ("\n%d\n",i) ;

One undefined behavior: the argument corresponding to the %d is not an
int.

return 0;
>}
>
>void f()
>{
int j=20;
*(&j+2)+=7;

A second undefined behavior: the expression &j+2 computes an address
that is beyond the end of j and not equal 1 beyond the end.

A third(?) undefined behavior: even &j+2 were to point to an int, its
value would be indeterminate and cannot be evaluated for the +=
operator.

>}
>
>I found this question in the internet. The output is 20. Even I didn’t
>believe this till I executed this program.
>The probable explanation will be:
>
>&j refers to the address of j.
>&j + 2 refers to the address next to j(since j is of type <int).
>This may be place where the return address is stored.(i think the
>return address is stored immediately after the variables).
>
>That value is incremented by 7.
>May be the assignment statement takes 7 bytes to be represented in the
>macine language.
>Therefore the assignment statement in the main(),<i=10wil l be
>skipped.
>So the value of "i" is never altered.
>
>
>Is my explanation correct..??

While the information may be true for your system, it is not correct.
The only correct statement is the program invokes undefined behavior.


Remove del for email

[Antoninus Twink]

Re: Is this correct..??

On 27 Apr 2008 at 4:20, jt wrote:
[snip]

&j refers to the address of j. &j + 2 refers to the address next to
j(since j is of type <int). This may be place where the return
address is stored.(i think the return address is stored immediately
after the variables).
>
That value is incremented by 7. May be the assignment statement takes
7 bytes to be represented in the macine language. Therefore the
assignment statement in the main(),<i=10wil l be skipped. So the
value of "i" is never altered.
>
Is my explanation correct..??

Your explanation is extremely plausible. Why don't you disassemble the
code produced by your compiler and check?

[nembo kid]

Re: Is this correct..??

jt ha scritto:

*(&j+2)+=7;

My guess:
Bad pointer,
you are deferencing something that it is not initialized.