Is casting could lead to a issue???

Question

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)

Answer 1

I'm not a C++ expert, but what you've described does not make any sense. Casting from an 8-bit type to a 16-bit type cannot result in uninitialized memory being incorporated into to the value--upcasts of this type have narrow, strictly-specified semantics, and the compiler can't just grab an extra adjacent byte and add it to your value.

What you're describing sounds like a buffer overflow from some other part of the program. I suggest using a validation tool like valgrind (Linux) or AppVerifier (Windows) to check your memory accesses and find the buffer overflow at its source.

Answer 2

Casting an integer to a larger integer is always safe.

It sounds like your program has a stack corruption issue occurring somewhere that is overwriting the value of your function parameter.

Your second paragraph makes a little sense in that one potential cause of this sort of error is a collision between the stack and the heap (i.e. out of memory), but the logic you've expressed is fundamentally wrong. The parameter of the Infected function is a copy of the argument. When you call Infected(rogue_int), the system isn't expanding the allocation of rogue_int to 16 bits at runtime, it is allocating a new variable for the parameter, which is 16 bits wide, and then copying the value of the 8-bit rogue_int into it. The value and allocation of the argument rogue_int itself are not modified, so it's certainly not the case that rogue_int is having another, uninitialized 8 bits tacked onto the end of it.