[Development] Urgent help needed: determining endianness at compile time in INTEGRITY

[Thiago Macieira]

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