bitfield并不具有可移植性，因此实际使用中，我都是尽量使用bitand来代替。
然而代码中之前就已经使用了bitfield的定义方式，作为后续开发我没有理由去改掉这个数据结构（除非它有问题），结果就无意间踩到了这个坑。
bitfield定义和使用大概如下：
union utest {
int val;
struct stest {
int a:3;
int b:5;
};
};
union utest t;
t.value = 0x07;
bitfield冒号后面的数字标识bitfield的位宽，bitfield前面的类型用于标识取出字段后应该变成一个什么样的类型(标准上说仅能支持int, signed int, unsigned int, 然而gcc还支持char, short等类型)。
问题的关键就在于，如果你定义的是有符号类型，那么编译器会将取出的bitfield按照有符号类型进行类型提升。
当程序读取变量stest::a时，他会读取utest::val的byte0的低3bit。由于stest::a的类型为int（有符号型类型), 则他将utest::byte0::bit2作为符号位进行整型提升。
也就是说如果utest::byte0::bit2~0的值为110b, 那么你读stest::a时,编译器会将bit2作为符号位来将110b整型提升为0xfffffffe, 即(int)-2;
在实际使用中我使用stest::b作为了一个数组的索引，当stest::b大于0x10时，数组访问直接越界了。
btw, 一般使用bitfield特性时应该很少去依赖于其符号扩展功能（即将其定义为有符号型类型）， 因此在将bitfield定义为int而不是unsigned int时一定要再三考虑。