LINUX 位域测试

ljmmail

#include  <stdio.h> #include  <string.h> #include  <ctype.h> int  main(int ac, char  *av[]) { &nbsp;&nbsp;&nbsp;&nbsp;struct { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a1:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a2:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a3:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a4:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a5:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a6:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a7:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a8:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a11:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a12:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a13:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a14:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a15:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a16:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a17:1 ; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned int  a18:1 ; &nbsp;&nbsp;&nbsp;&nbsp;} bb; &nbsp;&nbsp;&nbsp;&nbsp;int   c = 0x132f; &nbsp;&nbsp;&nbsp;&nbsp;memcpy(&bb, &c, sizeof(int)); &nbsp;&nbsp;&nbsp;&nbsp;printf("%d%d%d%d %d%d%d%d ", bb.a1, bb.a2, bb.a3, bb.a4, bb.a5, bb.a6, bb.a7, bb.a8); &nbsp;&nbsp;&nbsp;&nbsp;printf("%d%d%d%d %d%d%d%d \n", bb.a11, bb.a12, bb.a13, bb.a14, bb.a15, bb.a16, bb.a17, bb.a18); &nbsp;&nbsp;&nbsp;&nbsp;return 0; }

使用如上的程序进行测试，怎么得到的结果为
1111 0100 1100 1000
而不是我希望的
0001 0011 0010 1111

drowndog

这个结果，跟你用的操作系统的关系不大，关键是字节序，而对字节序起关键作用的是硬件结构。
同样是Linux，在power服务器或者SUN SPARC小型机上，结果就不同。

这里，很明显，你的机器是小端字节序的。
那么，c在内存中的排列就是：0x2f,0x13,0x00,0x00
memcpy后，bb在内存中的排列就是：0x2f,0x13  (BTW, 你的memcpy越界了)
小端字节序在解释位域时，是从bit0开始向bit7读取的，也就是说，bb中的a1对应bit0, a2对应bit1，以此类推

如果想在各个平台之间移植：
1. 少用位域
2. 如果一定要用，记得在不同的机器上调整位域定义的顺序（比如把a8先定义，最后定义a1），或者修改赋值处的代码，尽量少使用memcpy来赋值。

ljmmail

本来还准备使用上面方法进行数值解析处理，看来是不行的，只能使用 位运算进行数据处理了。

ljmmail

<code>
#include  <stdio.h>
#include  <string.h>
#include  <ctype.h>
int  main(int ac, char  *av[])
{
    struct {
         unsigned int  a1:1 ;
         unsigned int  a2:1 ;
         unsigned int  a3:1 ;
         unsigned int  a4:1 ;
         unsigned int  a5:1 ;
         unsigned int  a6:1 ;
         unsigned int  a7:1 ;
         unsigned int  a8:1 ;
         unsigned int  a11:1 ;
         unsigned int  a12:1 ;
         unsigned int  a13:1 ;
         unsigned int  a14:1 ;
         unsigned int  a15:1 ;
         unsigned int  a16:1 ;
         unsigned int  a17:1 ;
         unsigned int  a18:1 ;
         unsigned int  a21:1 ;
         unsigned int  a22:1 ;
         unsigned int  a23:1 ;
         unsigned int  a24:1 ;
         unsigned int  a25:1 ;
         unsigned int  a26:1 ;
         unsigned int  a27:1 ;
         unsigned int  a28:1 ;
         unsigned int  a31:1 ;
         unsigned int  a32:1 ;
         unsigned int  a33:1 ;
         unsigned int  a34:1 ;
         unsigned int  a35:1 ;
         unsigned int  a36:1 ;
         unsigned int  a37:1 ;
         unsigned int  a38:1 ;
    } bb;

    int   c = 0x132f;
    memcpy(&bb, &c, sizeof(int));
    printf("0x%x  ", c );
    printf("%d%d%d%d %d%d%d%d ", bb.a1, bb.a2, bb.a3, bb.a4, bb.a5, bb.a6, bb.a7, bb.a;
    printf("%d%d%d%d %d%d%d%d ", bb.a11, bb.a12, bb.a13, bb.a14, bb.a15, bb.a16, bb.a17, bb.a1;
    printf("%d%d%d%d %d%d%d%d ", bb.a21, bb.a22, bb.a23, bb.a24, bb.a25, bb.a26, bb.a27, bb.a2;
    printf("%d%d%d%d %d%d%d%d \n", bb.a31, bb.a32, bb.a33, bb.a34, bb.a35, bb.a36, bb.a37, bb.a3;
    return 0;
}
</code>

使用上面的代码进行测试，得到结果为：

0x132f  1111 0100 1100 1000 0000 0000 0000 0000

测试环境为 MagicLinux 2.5

liyaoshi

我不懂cpu
正好看see mips run
上面说lh是16位的

ljmmail

我看到了这样的显示：

0x7126032f  1111 0100 1100 0000 0110 0100 1000 1110

与我需要查看的结果完全反向，看来小端优先的机器，在内部存储的时候，应该是整个 32 位数据全部反向的。