Re: Help: How to determine big/little endian?

> paysan@informatik.tu-muenchen.de (Bernd Paysan) writes:
>> [How often in otherwise platform independent code do you really need to know
>> the byte order? I've almost always been able to program around it without
>> much trouble. -John]
>
>In code where you desire to have a specified byte order, thus read/writing
>binary file formats accross platforms, network code, or (this is where I
>need it ;-) processor simulation (because the simulated processor isn't
>wanted to inherit the host's byte order).


Very good answers. And here's another one, that actually requires
massive algorithmic changes! What if you have a data structure containing
variable length data, and the program uses a bit flag in the first
byte's MSB to specify whether the item is e.g. 1 byte long or 4 bytes long.


But oops, that doesn't work when the program is ported to e.g. an 80x86,
because now that byte doesn't come first, and also its leading bit
flag screws up the middle of the 4 byte value, rather than being
in the MSB where it can be safely stripped.


Therefore an entirely different algorithm and data structure are
required for big endian versus little endian. Or the entire problem
needs to be approached in a different way.


Yet the original algorithm seems very clean to someone accustomed to
Big Endian, until they explicitly think about Endian issues. (Obviously
it wouldn't even occur to someone steeped in Little Endian.) Usually
Endian problems only come up with "ugly" practices; the above is IMHO an
exception.


Unfortunately, there is almost always some situation that causes severe
trouble even in the face of ideal programming practices, no matter which
particular practice one considers. (The ancient "goto" debate comes to
mind...)
Doug
--
Doug Merritt doug@netcom.com


[Variable length integers seems to me a classic place for byte
shifting and masking in an endian-independent way. Try it, you'll
like it. I used to read network data structures with a big fread()
followed by trying to byte-swap the parts that needed it. Then I
wised up and read such stuff a value at a time with little routines
that, e.g. read a two-byte bigendian integer. It's a lot easier to
debug, and unless you're writing router code, the slowdown is
insignificant. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.