[9fans] xd

[9fans] xd

[hugo rivera]

I have an xd(1) question. Am I wrong or xd gets the byte ordering wrong?
1. While working on native plan 9 I always got the opposite byte
ordering from what I expected.
2. xd output from p9p shows exactly the opposite byte ordering that
hexdump output.
Perhaps there's something wrong with xd.
--
Hugo

Re: [9fans] xd

[erik quanstrom]

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

Re: [9fans] xd

[hugo rivera]

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