The short version:
When running in debug mode the system changes pointer values at runtime.
This mostly will go unnoticed because the debugging IDE reports the correct values and even does the correct maths. So if you try doing the following:
((size_t)(&FunctionOne)) - ((size_t)(&FunctionTwo))
If you look at the result in the debugging IDE you might get (real example):
((size_t)(0x011ee0e0)) - ((size_t)(&0x011ee050)) = 0x00000090
However, if you try an apply this in your running code you get instead:
((size_t)(0x011d132f)) - ((size_t)(0x011d137a)) = 0xffffffb5
Now, I get what its trying to do here (at least I think I might) its actually adding a call stub to the functions which probably adds a bunch of debug checks to try and help out a poor developer.
Whats majorly annoying is:
- It does not translate the addresses consistantly! So (like in the above example) addresses which where previously ordered top to bottom are transposed to the opposite effective order.
- If you attempted to perform an in memory transfer of this functions data you would copy garbage (or at least not the function proper).
- Maths carried out on pointers is completely meaningless (e.g. deriving the length by the difference between two pointers is not possible, though arguably this is bad practice anyway).
- Confusing because the IDE reports the correct values, addresses and maths (e.g. results in IDE will not match results of performing exact same math in code).
