In************@ gmail.com wrote:
Hi,
If I am right Endianness is CPU related. I do not know if the
question is right in itself but if it is then how does C handle issues
arising out of Endianness.
By ignoring them.
I understand that if we pass structures using sockets across platforms,
we need to take care of Endianness issues at the application level. But
for example, for the code using bitwise AND to figure out if a number
is odd or even, how does C know the LSB position?
On any particular implementation, the LSB of the unknown
value being tested is in the same position as the LSB of the
constant 1 you are ANDing with it. Problem solved.
Problems can occur when you exchange data between dissimilar
implementations , because they may disagree about endianness. They
may disagree about other matters of representation, too: one
platform might represent an int with sixteen bits while the other
uses thirty-two, one might use IEEE floating-point while the other
uses the S/360 format, the two might insert padding in structures
differently, and so on. Endianness is just one of a number of
representationa l issues you must consider when communicating
between different systems.
One approach that has proven widely useful is to invent a
"wire format" for the data to be exchanged, a format that does
not depend on the peculiarities of the machines. Each machine
then needs two routines: One to read "wire format" and convert
it to native representation, and one to convert the native form
to "wire format." For obvious reasons, many extrememly popular
"wire formats" use textual representations : If you want to send
the value forty-two, you transmit the two characters '4' and '2',
possibly followed by a delimiter like '\n' or ';' or some such.
This doesn't solve every possible problem (because the encoding
of characters can also vary from machine to machine), but it solves
a great many of them and usually leaves a fairly tractable remnant
to deal with.
--
Eric Sosman
es*****@acm-dot-org.invalid
