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.
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=10> will 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.
