Re: Problem with a Pointer

From: Stephen Sprunk (stephen_at_sprunk.org)
Date: 03/16/05 

Date: Wed, 16 Mar 2005 09:40:37 -0600

<ghyott@yahoo.com> wrote in message
news:1110984096.266438.253260@l41g2000cwc.googlegroups.com...
>
> First of all,I apologise for posting a moronic question.
> I made a foolish mistake(taking ret in place of *ret ) while I was
> trying to debug my problem.
> I have taken ret+12,because it now the ret will point to the return
> address of the funct(...).

(ret+12) points to an unspecified location. There is no guarantee that
location has _anything_ to do with the return address of the function, that
your program owns that memory, or that it's even a valid address.

>Next step i.e. (*ret)+=23; changes the return address to
> another specified address,

No, it changes the value of some unspecified data in an unspecified
location -- unless the pointer is invalid and the system traps it, in which
case your program terminates.

> so the control will jump to some other location instead of going to its
> intended location which was set when the funct was called.

No, it invokes undefined behavior. The data at (ret+12) might happen to be
your oven's temperature, and changing it could burn your dinner. Or it
might do what you think it does. You have no way of knowing.

> Although, it was looking easy but the things were not going as planned
> and I still don't know why it is so?

It's not going as planned because you're expecting undefined behavior to be
reliable, and it isn't. Even if it seems to work at one time, it could fail
next time you recompile due to a new version, different optimization, etc.
It's certainly unlikely to work on a different platform.

S 

-- 
Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin