Do you have a question? Post it now! No Registration Necessary
Subject
- Posted on
Big Endian or Little Endian?
- 08-11-2009

Re: 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
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
We've slightly trimmed the long signature. Click to see the full one.

Re: Big Endian or Little Endian?

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;
}

Re: Big Endian or Little Endian?

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.
:-)

Re: Big Endian or Little Endian?

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?

Re: Big Endian or Little Endian?

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.
--
Tauno Voipio
Tauno Voipio
Site Timeline
- » VDC Needs Your Help Studying Embedded Engineering Market
- — Next thread in » Embedded Linux
-
- » ioremap_nocache
- — Previous thread in » Embedded Linux
-
- » Crosscompiling for ARM: reloc type R_ARM_ABS32 is not supported for PIC - ...
- — Newest thread in » Embedded Linux
-
- » OT A modest proposal
- — The site's Newest Thread. Posted in » Electronics Design
-
- » Low Noise Direct Coupled Preamp
- — The site's Last Updated Thread. Posted in » Electronics Design
-