Regarding endianness determination, I built this simple program (thanks 
stackoverflow!)

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int is_big_endian(void)
{
     union {
         uint32_t i;
         char c[4];
     } bint = {0x01020304};

     return bint.c[0] == 1;
}

int isLittleEndian()
{
     short int number = 0x1;
     char *numPtr = (char*)&number;
     return (numPtr[0] == 1);
}
/*
  *
  */
int main(int argc, char** argv) {

     int result;
     result = is_big_endian();
     printf("First test, is Big Endian : %s\n",result ? "True" : "False");
     //printf("Raw result: %d\n",result);

     result = isLittleEndian();
     printf("Second test, is Little Endian : %s\n",result ? "True" : 
"False");
     //printf("Raw result: %d\n",result);
     return (EXIT_SUCCESS);
}

Both methods return little_endian on both my x86 and my ARM machines.
So endianness shouldn't be the problem.

I'm now recompiling roscpp with a few printfs where Cedric indicated to 
see what's happening, but only on the ARM.
On the x86 I have ROS installed from binaries and I'd rather not 
recompile everything there too.

Claudio


On 28/11/12 22:26, Brian Gerkey wrote:
> I also suspect that it's an endian mismatch, which I mentioned in 
> answer to this question at ROS Answers:
> http://answers.ros.org/question/49136/arm-buffer-overrun-debug-help/
>
> There I suggested changing the endianness of the embedded machine; 
> I've never done it myself, but I think that ARM processors can usually 
> be switched between big and little endian.  As Cedric has pointed out, 
> making roscpp endian-aware would be better, but making all of your 
> machine little-endian is a pragmatic workaround.
>
> Btw, if your ARM is running big-endian, then that's almost certainly 
> the problem.  You should run a sample program to determine that 
> machine's endianness (look around for an example).
>
>     brian.