Re: Arrrrrrrrrrrrggggg!!

From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 03/05/05 

Date: Sat, 05 Mar 2005 18:43:51 GMT

"Beth" <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message
news:TVeWd.178$k72.0@newsfe2-gui.ntli.net...
> TS wrote:
> > Herbert wrote:
> > >Sorry, but C hides any big-endian or little-endian of the
> > >processor. So, if you don't include any inline assembler code
> > >in your C code, this can't be a problem at all.
> >
> > Write a "long" to memory, get its address, use this addres for reading
> > the first byte of it with a byte pointer - guess what happens...
>
> Yeah, sorry...but he's quite right that this is nonsense...C hides
> "endianness" exactly as far as assembly language does...
>
> That's the purpose of the standard "hton" ("host to network") and "ntoh"
> ("network to host") functions in C (usually standard UNIX functions: They
> exist in Minix, for sure :)...as C _DOESN'T_ hide "endianness" at all,
> these functions are used to "insulate" the program from endianness
> considerations...otherwise, _yes_, the program _WOULD_ be effected by
> endianness and it _would_ be wrong because of it...C itself does NOT do
> anything that, in fact, the underlying chips themselves do (after all, x86
> processors "hide" the fact that they are little endian, so to speak, by
> re-arranging the bytes as memory is accessed...do the same kind of test in
> ASM and the same result as C emerges: Create a dword in memory, get its
> address, use this address for reading the first byte and, yeah, guess what
> happens there too...C does nothing more nor less than, in fact, the
machine
> itself does ;)...

Works great for two's complement binary integers.
Now what happens with other numbering systems?

>
> The "trick" with the "hton" and "ntoh" functions is that on little-endian
> machines, these functions do all the required byte swapping...but on
> big-endian machines, they do absolutely nothing...hence, it makes the
> source code "portable" because the functions are defined to resolve to
> whatever's appropriate for the "host" machine...if needed, they are byte
> swapping functions...if not needed, they resolve to nothing (indeed, use
an
> "empty" macro with conditional compilation to literally remove them at the
> pre-processing stage, so it costs nothing: "#define htons(arg)", as the
> functions can be "wiped out" at the pre-processing stage...in practice,
> unfortunately, this can be too "specific" and not very flexible, leading
to
> actually making them "empty functions"...all the "call overhead", no
actual
> point in doing so)...

The catch here is that C is *not* hiding endianess. There are some
library routines one can call to allow for endianness, but you could
do this in assembly, too.

Cheers,
Randy Hyde