endian dilemma

[gaf at blu.org (Jerry Feldman)]

Silicon Graphics systems are big endian, Intel systems are little endian. 
There are many solutions available. Many network solutions use methods for 
each field with a type code, length, data. Integer data is generally 
transmitted in network byte order. There are network functions that convert 
from net byte order to host byte order (little endian in your case). 

The functions are:
int ntohl(int) 	convert a 32 bit integer from net to host
int htonl(int)	convert a 32 bit integer from host to net
short ntohs(short) 	convert a 16 bit integer from net to host
short htonl(short)	convert a 32 bit integer from host to net
Note that l stands for long because the idiot who designed those functions 
made an erroneous assumption that longs were 32 bits, which is not true on 
most 64 bit systems. 


On 5 Sep 2002 at 13:54, Gregory Gimler wrote:

> Hello all,
> 
> 	I have an interesting problem concerning endian conversion.  I'm helping 
> to port some software over from an O2 to linux.  The software that 
> transmits messages, I have no control over and it can't be modified.  There 
> are several different formats to the messages being transmitted.  Does 
> anyone know of a solution already on the internet somewhere or have any 
> suggestions on how I might approach this problem so I can still read the 
> messages, even though I'm on a little endian machine?  Thanks.
> 
> 
> 
> 																	-Greg
> 
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss


-- 
Jerry Feldman <gaf at blu.org>
Associate Director
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9