Uh, thanks for the reply.
Now that I think about it endianness was the obvious reason behind this.
Saludos
2009/5/20, erik quanstrom <quans...@quanstro.net>:
> On Wed May 20 06:57:14 EDT 2009, uai...@gmail.com 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
>
>
--
Hugo
