beginner question, byteorder.h

Milan Bella milanbella at
Sun Nov 18 20:46:40 GMT 2007

What is the deafult byteorder of SMB packet ?

There's a following comment in byteorder.h:

> Ok, now to the macros themselves. I'll take a simple example, say we
> want to extract a 2 byte integer from a SMB packet and put it into a
> type called uint16 that is in the local machines byte order, and you
> want to do it with only the assumption that uint16 is _at_least_ 16
> bits long (this last condition is very important for architectures
> that don't have any int types that are 2 bytes long)

> You do this:

> #define CVAL(buf,pos) (((unsigned char *)(buf))[pos])
> #define PVAL(buf,pos) ((unsigned)CVAL(buf,pos))
> #define SVAL(buf,pos) (PVAL(buf,pos)|PVAL(buf,(pos)+1)<<8)

In my opinion the only one assumption  that uint16 is _at_least_ 16
long is not sufficent. The packet byteorder
must be known beforehand, for if not then we cannot interpret the
packet value at pos at all.

Say, for exapmple,  that left bit shifh shifts byte always in
direction from least significant to most significant byte, then left
bit shift "must know the byte order of maschine" and we can use this
implicit knowledge in writing the portable code. But this does not
save us from the fact that the byte order of input data must be  fixed

Let say that  packet value at pos is in little endian:
pos: LSB MSB

maschine is little endian
*(pos+1)<<8               :   0   MSB
*(pos+1)<<8  |  *pos  :   LSB MSB


maschine is big Indian
*(pos+1)<<8:             :   MSB   0
*(pos+1)<<8  |  *pos  :   MSB   LSB

But what happens if packet value at pos is in big endian ?, we end up
with incorrect value having bytes swaped.
Bit shift is simply not so smart to know what byte order we had in
mind when we wrote the value at p in packet.


More information about the samba-technical mailing list