hi Dennis ,
thanks a lot for the pain you have take in clearing things
for me :-). I have some doubts left but -
1) i send an integer over the network
unsigned short tempx = 0x1000;
this would be stored as 0x0010; on a little endian machine. Now i sned this
unsigned short over the network to a big endian
machine - can the big endian machine interpret it properly ? i.e does the
tcp/ip stack do something to take care of this ?
or does the conversion to network byte ordering ( to big endian by the
tcp/ip stack) happen only with the headers ?
if possible, please explain what would happen in the above case .
cheers,
Amith
Dennis McCracken wrote:
> -----Original Message-----
> From: kernelnewbies-bounce@nl.linux.org
> [mailto:kernelnewbies-bounce@nl.linux.org]On Behalf Of Amith
> Sent: Wednesday, February 11, 2004 12:26 AM
> To: kernelnewbies
> Subject: Endianess .
>
> hi all,
>
> I had read about Little Endian and Big Endian byte
> ordering from some resources on the net.
> I had read that this doesnt affect char arrays and hence
> they can be used to overcome this problem.
> My question is
> char temp_char[2];
> unsigned short temp_short;
>
> Don't they finally end up to 2 bytes of physical memory
> ? and so why is it that it doesnt affect
> char arrays . iam sure that i have missed something
> .Please throw some light on this one.
>
> thank you.
>
> cheers,
> amith
>
> Endianess refers to how any value larger than 8 bits (char) is stored in
> memory and is processor / device specific. The storage method or
> "endianess" is only an issue when the processor your code is running on uses
> a storage method different than that expected by another processor or bus
> device. Processors like Intel's Pentium use "little endian" storage.
> Motorola and PowerPC processors and most bus devices use what is called "big
> endian" storage. Though there are many devices that allow you to specify
> the endianess of a memory region they are accessing.
>
> Here are some specific examples:
>
> char foo[4] = {0, 1, 2, 3};
> appears in memory as:
> 0x100: 0x00, 0x01, 0x02, 0x03
>
> This is true of both big endian and little endian architectures because
> there is only 8 bits stored in each array element.
>
> short foo[4] = {0, 1, 2, 3};
> appears in memory as:
> < foo[0] > < foo[1] > < foo[2] > < foo[3] >
> foo: 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x03
> foo: 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x03, 0x00
> < foo[0] > < foo[1] > < foo[2] > < foo[3] >
>
> The first representation of a short above uses "big endian" storage. The
> second uses "little endian" storage. As you can see from the illustration,
> if two devices are using a different storage technique and a common storage
> format for exchanged messages is not enforced, they will misinterpret each
> other's data.
>
> When networks were first being developed a common or "network order" was
> established for the transmission of information. This network order also
> matches "big endian". Most well written and portable network code will use
> macros to store values larger than 8 bits (one character) into memory for
> consumption by another bus device. These macros are compiled out on big
> endian systems and force the proper ordering in memory in little endian
> systems.
>
> I hope this explanation helps clear things up for you.
>
> - Dennis -
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
