beginner question, byteorder.h

[Milan Bella]

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
beforehand.

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

LSB 0
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.

Regards,
                      Milan