We've got a change blocked because some third-party code is unable to find a macro that determines the endianness of the target while compiling with GHS's compiler for INTEGRITY.
Can someone help? Any of the following would help: (a) documentation link stating what macro is set (b) a simple test program in C that shows how to determine the endianness at compile time (c) a function that does 64-bit host-to-network and back conversions on INTEGRITY (d) an actual patch to TinyCBOR - https://github.com/intel/tinycbor (file src/compilersupport_p.h) Please note that Qt doesn't seem to have a problem -- qprocessordetection.h has an #error and it's not triggering. So it would seem Qt has a solution. I have not looked at the code because I need to submit to the third-party and I need therefore MIT-licensed solutions. A Qt Company employee could open qprocessordetection.h and determine how it makes this work -- the only other copyright holder of relevance in that file is Intel. For reference, TinyCBOR already tries these tests: __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ __BYTE_ORDER == __BIG_ENDIAN BYTE_ORDER == BIG_ENDIAN defined(__ARMEB__) || defined(__MIPSEB__) || defined(__sparc__) __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ __BYTE_ORDER == __LITTLE_ENDIAN BYTE_ORDER == LITTLE_ENDIAN defined(__ARMEL__) || defined(__i386) || defined(__i386__) || defined(__x86_64) || defined(__x86_64__) || \ defined(__amd64) || defined(__MIPSEL__) It's possible it's one of those and there's something else wrong. I don't have access to the toolchain and therefore can't test to see what it is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development