Hi all,

In one RTOS, i'm debugging one issue which is, program is crashing one point always when it send a 8-bit value (Lets call it 'Int8 rogue_int')to a function (lets call it 'Infected( Int16 )' ) whose definition is taking that variable as 16-bit variable. Before entering to that last function Infected(..), value for 'rogue_int' is proper but as soon as it enters to Infected(..) fn it is having some junk value and it hits a assert. normally my thinking is casting 8-bit to 16-bit variable should not result any issue but there could not be any other problem i can not find in between that could corrupt the static memory.

i have given it much thought and i came up some theory that since this is hitting assert after some time (lets say 2-3 hrs of execution) so initially static memory is nice and clean and not much grown towards heap but as it grows then during casting 8 bit to 16 bit, it takes 8 bits from real no (which is rogue_int here) but it takes additional 8-bits of memory chunk that was just assigned to this variable to make it 16-bit. this newly added 8-bit could be corrupted and that could make complete no as invalid.

My question here is that, does my 2nd para above make any sense to C++ experts?? Does casting 8 to 16 is always safe (I was thinking it is always safe that is why i'm not submitted my thoughts to higher up)?? if you think i'm wrong then please suggest alternative that could lead to this prob. (assert always seen hit ONLY at one point in function 'Infected(..)'... not any any other place)


Thanks..

If the 8 bit variable is passed by value then there should not be a problem because the compiler doesn't pass 8 bit values anyway, the smallest that can be put on the stack is 16 bit variables (with a 32-bit compiler on an Intel beased computer). Casting can lead to huge problems if the variable is passed by reference (or pointer) because then the receiving function will be expecting a pointer to a 16 bit variable.

Edited 6 Years Ago by Ancient Dragon: n/a

This question has already been answered. Start a new discussion instead.