Big Endian or Little Endian?

On August 11, 2009 11:00, in comp.os.linux.embedded, VT



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

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.

:-)

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?

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.