Re: [9fans] xd

[hugo rivera <uair00@gmail.com>]

Uh, thanks for the reply.
Now that I think about it endianness was the obvious reason behind this.
Saludos

2009/5/20, erik quanstrom <quanstro@quanstro.net>:
> On Wed May 20 06:57:14 EDT 2009, uair00@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