On Wed May 20 06:57:14 EDT 2009, [email protected] wrote:
> I have an xd(1) question. Am I wrong or xd gets the byte ordering wrong?
no. xd is correct. if you're running on an intel,
you're running on a little-endian machine which
means that numbers are stored in the reverse order
they are written.
#include <u.h>
#include <libc.h>
void
main(void)
{
uchar e[8] = {0, 1, 2, 3, 4, 5, 6, 7};
int i;
uvlong l;
l = *(uvlong*)e;
print("%.16llux\n", l);
l = 0x01020304050607ull;
memcpy(e, &l, 8);
for(i = 0; i < nelem(e); i++)
print("%.2ux", e[i]);
print("\n");
}
see http://en.wikipedia.org/wiki/Endianness
> 2. xd output from p9p shows exactly the opposite byte ordering that
> hexdump output.
> Perhaps there's something wrong with xd.
neither is wrong. hexdump is just underspecified. hexdump
doesn't say what the endianness of its output is. xd on the other
hand does:
Formats other than -c are specified by pairs of characters
telling size and style, `4x' by default. The sizes are
1 or b 1-byte units.
2 or w 2-byte big-endian units.
4 or l 4-byte big-endian units.
8 or v 8-byte big-endian units.
so numbers will be printed in reverse on an intel machine.
but the same network packet will be printed the same way
by xd on a big-endian sender and a little-endian recipient.
- erik
