Big Endian or Little Endian?

The print statement above exhibits neither "big endian", nor "little endian" (or /any/ "endian") arrangement. It does, however, exhibit several unnecessary conversions.

So, let's look at it:

• pByte is presumably an array of char. Each pByte[] element is a single char value, and as such has no /endian/ quality. Taken as an /array/, pByte could be considered "big endian", but only in that is the way C defines /all/ arrays.

• Within the argument list for the printf() function call, the programmer has opted to explicitly cast each pByte[] char element into an integer. This was unnecessary, as printf() is a variadic function, and arguments after the format string (those pByte[] elements) would have been implicitly converted to integer by the compiler.

Now, the effect of the implicit or explicit cast depends on how pByte[] was defined. If pByte[] is an array of signed char", or an array of "char", then the cast will cause the compiler to interpret each pByte[] as a signed value (even if it is not), and sign-extend the value into it's resulting integer. ("unsigned char" would not sign-extend into int) This will cause the printf() to produce improper results, as pByte[] values greater than 127 will print as negative numbers, rather than positive numbers.

/As integers/, the endianness of the pByte[] values is not evident in your example. We cannot tell if the resulting integers are "big endian" or "little endian".

HTH

If actual "endianness" needs to be determined, following is a small routine I wrote that has worked reliably across every CPU to which I've had access. I was intrigued to note the ARM processor in my SheevaPlug systems is little- endian.

/*---------------------------------------------------------------------- * CHECK_ENDIAN -- recognize and identify three kinds of endian-ness * * Returns: * 0 = unknown * 1 = big-endian (MC68K, HP-PA RISC, Sun, RS6000, SGI) * 2 = little-endian (VAX, Alpha, Intel) * 3 = PDP-11 endian * * Author: Thad Floryan, 14-May-1992 */ int CHECK_ENDIAN() { unsigned int u = 0x01234567; unsigned char *p = (unsigned char *)&u;

if (0x01 == *p) return 1; if (0x67 == *p) return 2; if (0x23 == *p) { if (0x01 == p[1] && 0x67 == p[2] && 0x45 == p[3]) return 3; else return 0; }

return 0; }

You're not being completely logical here: you do check the weird PDP-11 endianess for all octets, but only for the first octet of little-endian and big-endian.

The logic is complete: All other outcomes return 0 "unknown". If you know of another "endianess", please add to the program. I didn't even know about the PDP-11 ;-) but now I do. Thanks, Thad. Bob

Oh? Since the early 1960s I haven't seen anything other than big endian, little endian, and PDP-11-endian, so why check all octets for big/little when a single octet will suffice?

Are you aware of a computer today possessing something other than big or little endian-ness?

You're welcome!

It's actually "funny" how that PDP-11 endian-ness was discovered. A colleague had one of the Heathkit LSI-11 systems with that odd alignment, and I confirmed it later across all PDP-11 systems through some contacts at DECUS.

Many other systems I used back in the 1960s were big-endian: CDC 3000s, IBMs, Burroughs, SDS-930/-940, DEC PDP-10, Honeywells, Xeroxs, etc etc.

I couldn't use that C routine back then -- had to look at the console lights.

:-)

Read the above again: I comment that for big-endian and little-endian results, 6 different octet orders are accepted for both. It is not logical that the PDP-11 longword order is checked for all octets, but the other are not.

The point is that either all results should be checked for all four octets, or all are identified by the first octet only. Now, 10 weird orders (out of a total of 24 possibilities) are accepted as little-endian or big-endian.