Function stack reallocation

Function stack reallocation

[Reggie Cushing]

Hi All - I wish some insight on the possibility of reallocating a 
function stack to a malloced regions in realtime ie I jump out of a 
function and the next time I jump in the stack would have moved along 
with its data. To me it seems unreliable cause the values in the stack 
have no type hence I would not know if the stack value is a data value 
or a pointer. If I mistakenly interpret a data value as a pointer I will 
update the data value resulting in data corruption. I would really wish 
some expert insight in this on this subject.

Regards
R.

Re: Function stack reallocation

[Per Jessen]

Reggie Cushing wrote:
> Hi All - I wish some insight on the possibility of reallocating a
> function stack to a malloced regions in realtime ie I jump out of a
> function and the next time I jump in the stack would have moved along
> with its data. To me it seems unreliable cause the values in the stack
> have no type hence I would not know if the stack value is a data value
> or a pointer. If I mistakenly interpret a data value as a pointer I will
> update the data value resulting in data corruption. I would really wish
> some expert insight in this on this subject.

What you're talking about is something long these lines:

a=malloc(chunk);
memcpy( chunk, SP, size);
SP=chunk;


The only way you "know" what's on your stack is by the variable
declarations you've made in your code.  The stack, wherever it is, does
not contain any type info.


/Per Jessen, Zurich

Re: Function stack reallocation

[Reggie Cushing]

cheers for the clarification, very much appreciated.

R.

Per Jessen wrote:
> Reggie Cushing wrote:
>   
>> Hi All - I wish some insight on the possibility of reallocating a
>> function stack to a malloced regions in realtime ie I jump out of a
>> function and the next time I jump in the stack would have moved along
>> with its data. To me it seems unreliable cause the values in the stack
>> have no type hence I would not know if the stack value is a data value
>> or a pointer. If I mistakenly interpret a data value as a pointer I will
>> update the data value resulting in data corruption. I would really wish
>> some expert insight in this on this subject.

>> What you're talking about is something long these lines:
>>
>> a=malloc(chunk);
>> memcpy( chunk, SP, size);
>> SP=chunk;
>>
>>
>> The only way you "know" what's on your stack is by the variable
>> declarations you've made in your code.  The stack, wherever it is, does
>> not contain any type info.
>>
>>
>> /Per Jessen, Zurich
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>     

-- 
Reggie Cushing
Systems Engineer
310, Dept Computer Science and AI
University of Malta, MSD06, MALTA
Tel: +356 2340 2130 

Re: Function stack reallocation

[Neil Horman]

On Wed, Mar 28, 2007 at 09:21:30AM +0200, Reggie Cushing wrote:
> Hi All - I wish some insight on the possibility of reallocating a 
> function stack to a malloced regions in realtime ie I jump out of a 
> function and the next time I jump in the stack would have moved along 
> with its data. To me it seems unreliable cause the values in the stack 
> have no type hence I would not know if the stack value is a data value 
> or a pointer. If I mistakenly interpret a data value as a pointer I will 
> update the data value resulting in data corruption. I would really wish 
> some expert insight in this on this subject.
> 

Don't do it.  As you mention, you won't be able to conclusively detrmine if you
are moving a pointer in the stack or a data value to your new location (i.e.
arrays).  You could probably make it work most of the time, but you could never
guarantee that you always got it right.  

Neil

> Regards
> R.
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html