Date: Tue, 23 Sep 2014 16:16:50 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 193649] ring->nr_buf_size will be calculated wrongly on PPC machine Message-ID: <bug-193649-8-oS9retnjoc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-193649-8@https.bugs.freebsd.org/bugzilla/> References: <bug-193649-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193649 --- Comment #1 from dongshan <thomasyang1206@126.com> --- the bug is caused as following: imaging a 32-bit integer 0x00000800, on little endian machine, the data in memory is arranged like this: [0000 0000] 0000 [0000 0001] 0000 [0000 0002] 1000 [0000 0003] 0000 [0000 0004] 0000 [0000 0005] 0000 [0000 0006] 0000 [0000 0007] 0000 However, on a big endian machine, the value in memory is: [0000 0000] 0000 [0000 0001] 0000 [0000 0002] 0000 [0000 0003] 0000 [0000 0004] 0000 [0000 0005] 1000 [0000 0006] 0000 [0000 0007] 0000 ------------------------------------------------------------------------------- Here is the trick: uint32_t foo; // let assume the address of foo is 0x0, as showed above. uint32_t *p = &foo; *(uint16_t *)p = 0x00000800; printf("foo: 0x%x", foo); // the output of foo will be 0x08000000 printf("foo1:0x%x", (uint16_t)foo); // the output will be 0x00000800 Dump the memory on big endian machine: [0000 0000] 0000 [0000 0001] 1000 [0000 0002] 0000 [0000 0003] 0000 [0000 0004] 0000 [0000 0005] 0000 [0000 0006] 0000 [0000 0007] 0000 -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193649-8-oS9retnjoc>