 |
|
| Linux Forum Index » Linux Embedded » Big Endian or Little Endian?... |
|
Page 1 of 1 |
|
| Author |
Message |
| VT... |
 Posted: Tue Aug 11, 2009 5:00 am |
|
|
|
Guest
|
Is this below print is Big-endian or Little Endian, since array begins
with upper byte, this is Big Endian mode, am I correct?
printf( " source_ip_adr = %d.%d.%d.%d\n",
(int)pByte[0], (int)pByte[1], (int)pByte[2], (int)pByte
[3]); |
|
|
| Back to top |
|
|
|
| Lew Pitcher... |
| Posted: Tue Aug 11, 2009 9:17 am |
|
|
|
Guest
|
On August 11, 2009 11:00, in comp.os.linux.embedded, VT
(tvnaidu at (no spam) hotmail.com) wrote:
Quote: Is this below print is Big-endian or Little Endian, since array begins
with upper byte, this is Big Endian mode, am I correct?
printf( " source_ip_adr = %d.%d.%d.%d\n",
(int)pByte[0], (int)pByte[1], (int)pByte[2], (int)pByte
[3]);
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
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------ |
|
|
| Back to top |
|
|
|
| Thad Floryan... |
| Posted: Tue Aug 11, 2009 4:01 pm |
|
|
|
Guest
|
On 8/11/2009 8:17 AM, Lew Pitcher wrote:
Quote: [...]
/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".
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;
} |
|
|
| Back to top |
|
|
|
| Tauno Voipio... |
| Posted: Wed Aug 12, 2009 12:45 pm |
|
|
|
Guest
|
Thad Floryan wrote:
Quote: On 8/11/2009 8:17 AM, Lew Pitcher wrote:
[...]
/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".
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.
--
Tauno Voipio |
|
|
| Back to top |
|
|
|
| Bob... |
| Posted: Wed Aug 12, 2009 1:50 pm |
|
|
|
Guest
|
Tauno Voipio wrote:
Quote: Thad Floryan wrote:
On 8/11/2009 8:17 AM, Lew Pitcher wrote:
[...]
/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".
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 |
|
|
| Back to top |
|
|
|
| Thad Floryan... |
| Posted: Wed Aug 12, 2009 3:00 pm |
|
|
|
Guest
|
On 8/12/2009 11:45 AM, Tauno Voipio wrote:
Quote: [...]
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.
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? |
|
|
| Back to top |
|
|
|
| Thad Floryan... |
| Posted: Wed Aug 12, 2009 3:31 pm |
|
|
|
Guest
|
On 8/12/2009 12:50 PM, Bob wrote:
Quote: Tauno Voipio wrote:
Thad Floryan wrote:
[...]
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.
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.
:-) |
|
|
| Back to top |
|
|
|
| Tauno Voipio... |
| Posted: Thu Aug 13, 2009 12:05 am |
|
|
|
Guest
|
Thad Floryan wrote:
Quote: On 8/12/2009 11:45 AM, Tauno Voipio wrote:
[...]
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.
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.
--
Tauno Voipio |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Tue Dec 01, 2009 12:39 pm
|
|