From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Wed, 20 May 2009 07:39:24 -0400 To: 9fans@9fans.net In-Reply-To: <138575260905200355v56c017feja3a650d315b72fa3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] xd Topicbox-Message-UUID: fb62e69c-ead4-11e9-9d60-3106f5b1d025 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 #include 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