# Revision history [back]

Okay, so a few things... first of all, I think the garbled variables were due to compile-time optimization. Once I disabled C/C++ optimization, the variables looked much more reasonable.

Disabling optimization also allowed me to realize that the problem has nothing to do with memcpy- it's due to the following lines:

 uint32_t * length_message_type = (uint32_t *)(outbuffer + offset);
*length_message_type = strlen( (const char*) this->message_type);


The real cause of this error, I think, is a problem with memory addressing. If I add '1' to outbuffer + offset above, the assignment works fine (although the program fails later on). So it would seem that length_message_type is partially overwriting the variable defined just before it. I'll probably open a trac bug for this, but I welcome any suggestions on how to fix this myself.

Okay, so a few things... first of all, I think the garbled variables were due to compile-time optimization. Once I disabled C/C++ optimization, the variables looked much more reasonable.

Disabling optimization also allowed me to realize that the problem has nothing to do with memcpy- it's due to the following lines:

 uint32_t * length_message_type = (uint32_t *)(outbuffer + offset);
*length_message_type = strlen( (const char*) this->message_type);


The real cause of this error, I think, is a problem with memory addressing. If I add '1' to outbuffer + offset above, the assignment works fine (although the program fails later on). So it would seem that length_message_type is partially overwriting the variable defined just before it. I'll probably open a trac bug for this, but I welcome any suggestions on how to fix this myself.

EDIT: The problem was indeed with memory alignment. Rosserial was written for the Arduino, an 8-bit platform, but I am implementing it on an STM32F0, a 32-bit platform. On 32-bit platforms, you must take care when writing to RAM that the address is divisible by 4 for proper alignment.