不懂为什么我给了一个我觉得很好的建议但反而遭致谩骂和不解？！
我们总是谩骂为什么国外的技术总是那么厉害而我们的不行！
我们总是谩骂为什么别人的工资可以很高而且还可以升职而我们不行！
我们总是谩骂为什么一个程序到我这就总是会出现问题！
其实，根本上是自己的水平有限而又不静下心来去学习！
我欣赏有不同的意见，这样大家会持续讨论从而互相进步，而不是肆意武断给出结论甚至还遭致谩骂，我想从谩骂这点来看你的素质和教养是低下的，你的工作诚然也是失败的。

从楼主这个题目来看，首先我们必须认识到语法本身的严谨性，同时还需要考虑程序的兼容性，除了这些，项目本身还应该有可维护性和扩展性，无论如何如果还未意识到这些的其中一些或者全部，从我的经验看项目本身要么很小或者不再维护，要么项目实际运行时效果很差。我这里说的是实际项目，不是跑个流水灯或过一遍程序示例代码。
以下，摘录ARM CMSIS中的core_cm4.h里面的关于位域的一个代码片段：

同时，我检索了ST的cube源代码库和ARM CMSIS代码库，只要有位域的都是uint32_t来声明的，我们从中应该学到一些东西。
另外，关于为什么楼主的例子是可行的问题，不用再争论了，我强调的是语法本身的严谨性、程序的兼容性、项目的可维护性和扩展性。
共勉吧！

MSP430的IO库里面一堆unchar 申明位域的， 有时候一味扣字眼做什么， C语言通用性 可变性强的很。

初始化 那啥，确实是位域，我脑残了。 因为这是一个不被推荐使用，而我也不用的语法点，所以。 我也忘了 本帖最后由 辛昕 于 2016-7-13 10:10 编辑

心平气和讨论，没人有要骂你的意思，你说的那个只能是 u32，说实话我第一次听到，看完震惊了。
Ps；st的用u32很好理解，因为这些芯片是32位的，寄存器本身就是32位的，用u32无可厚非。uchar定义的位域不是没有。。。

不应该骂你的，评论已删

的确有人在骂，只是现在投诉后已经删除了：

所以，即使讨论再激烈也只是技术讨论，跟人品素质都还扯不上，但骂人的人真是不知道怎么想的。

这个论坛是STM32/STM8，想必很多同学在用stm8，这个我没用过，估计是8位的单片机，用的编译器和STM32可能不同。但万一，我指定是万一，你要升级STM8至STM32（这个万一概率往往比较大），尽管你用了uchar来声明了位域（这个是编译器所支持的，但这个支持超出了C语言的范围，但需要程序员清楚这个，原因？），在STM8上也编译通过了，但往往这类程序在移植时总是会出现这样那样的“奇怪”问题，如果你不知道这个uchar的位域的问题，那么对于解决这类移植来说花费的时间更长，反而你会觉得不如选择最不该选择的--重写代码，在重写代码时，惯性的还是使用uchar来声明位域，那么这个时候显然编译器是给出错误的（ARM-MDK acc会这样），如果你不知道这个uchar的位域的问题，这个时候你还是不知道，那么显然这个总是给你造成疑问和问题。
我指，尽管你现在可以用uchar，但你要知道有一天你可能要在这个地方留意，因为它是个C语言范围之外的应用，编译器更换后可能就不再支持了。

我来说说我的观点吧，其实我不太同意你7楼的看法，观点过于激进。

1. 你也承认了，除了unsigned int和signed int之外，可以使用其他的数据类型。

2. 考虑到可移植性的时候，位域特性尽量就别使用了，位域的可移植性涉及到处理器的位宽和字节序。在嵌入式领域位域通常用来对特殊功能寄存器进行声明，这种一般都没有移植的价值，就像你举的例子一样，同样没有可移植性，因为uint32_t与unsigned int并不等价，仅在你的编译器环境下才等价，在8位16位环境下就需要使用unsigned long类型来对应，因此uint32_t的使用也并不符合你的要求。可移植性的话题太大，就像int由于位宽问题也会导致移植问题，但是大多数人也还是在用。
如果确实要考虑广义的可移植性，那我建议就别使用位域功能了，直接使用位操作来代替。