[Bug 193649] ring->nr_buf_size will be calculated wrongly on PPC machine

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193649

--- Comment #1 from dongshan <thomasyang1206 at 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.