1.字、双字的含义
有些操作系统和处理器不把它们的标准字长称作字，相反，出于历史原因和某种主观的命名习惯，它们用字来代表一些固定长度的数据类型。比如说，一些系统根据长度把数据划分为字节（byte，8位），字（word，16位），双字（double words 32位）和四字（quad words 64位），而实际上该机是32位的。在本书中—在Linux中一般也是这样—象我们前面所讨论的那样，一个字就是代表处理器的字长。
对于支持的每一种体系结构，Linux都要将<asm/types.h>中的BITS_PER_LONG定义为C long类型的长度，也就是系统的字长。表1是Linux支持的体系结构和它们的字长的对照表。
表1 Linux支持的体系结构
| 体系结构 描 述 字 长 alpha Digital Alpha 64位 arm Arm and StrongArm 32位 cris CRIS 32位 h8300 H8/300 32位 i386 Intel x86 32位 ia64 IA-64 64位 m32r M32xxx 32位 m68k motorola 68k 32位 m68knommu M68k without MMU 32位 mips MIPS 32位 mips64 64位MIPS 64位 parisc HP PA_RISC 32位或64位 ppc PowerPC 32位 ppc64 POWER 64位 s390 IBM S/390 32位或64位 sh Hitachi SH 32位 sparc SPARC 32位 sparc64 UltraSPARC 64位 um Usermode Linux 32位或64位 v850 v850 32位 x86_64 x86-64 64位 |
C语言虽然规定了变量的最小长度，但是没有规定变量具体的标准长度，它们可以根据实现变化[唯一的例外是char，它的长度总是8位]。C语言的标准数据类型长度随体系结构变化这一特性不断引起争议。好的一面是标准数据类型可以充分利用不同体系结构变化的字长而无需明确定义长度。C语言中long类型的长度就被确保为机器的字长。不好的一面是在编程时不能对标准的C数据类型进行大小的假定，没有什么能够保障int一定和long的长度是相同的[事实上对于Linux支持的64位体系结构来说，long和int长度是不同的，int是32位的，而long是64位的。但对于我们所熟悉的32位体系结构而言，两种数据类型都是32位的]。
情况其实还会更加复杂，因为用户空间使用的数据类型和内核空间的数据类型不一定要相互关联。sparc64体系结构就提供了32位的用户空间，其中指针、int和long的长度都是32位。而在内核空间，它的int长度是32位，指针和long的长度却是64。没有什么标准来规范这些。
牢记下述准则：
* ANSI C标准规定，一个char的长度一定是8位。
*尽管没有规定int类型的长度是32位，但在Linux当前所有支持的体系结构中，它都是32位的。
* short类型也类似，在当前所有支持的体系结构中，虽然没有明文规定，但是它都是16位的（although no rule explicitly decrees that）。
*决不应该假定指针和long的长度，在Linux当前支持的体系结构中，它们就可以在32位和64位中变化。
*由于不同的体系结构long的长度不同，决不应该假设sizeof( int ) == sizeof( long )。
*类似地，也不要假设指针和int长度相等。
2. 不透明类型
不透明数据类型隐藏了它们内部格式或结构。在C语言中，它们就像黑盒一样。支持它们的语言不是很多。作为替代，开发者们利用typedef声明一个类型，把它叫做不透明类型，希望其他人别去把它重新转化回对应的那个标准C类型。通常开发者们在定义一套特别的接口时才会用到它们。比如说用来保存进程标识符的pid_t类型。该类型的实际长度被隐藏起来了—尽管任何人都可以偷偷撩开它的面纱，发现它就是一个int。如果所有代码都不显式地利用它的长度（显式利用长度这里指直接使用int类型的长度，比如说在编程时使用sizeof(int)而不是sizeof(pid_t)—译者注），那么改变时就不会引起什么争议，这种改变确实可能会出现：在老版本的Unix系统中，pid_t的定义是short类型。
另外一个不透明数据类型的例子是atomic_t，它放置的是一个可以进行原子操作的整型值。尽管这种类型就是一个int，但利用不透明类型可以帮助确保这些数据只在特殊的有关原子操作的函数中才会被使用。不透明类型还帮助我们隐藏了类型的长度，但是该类型也并不总是完整的32位，比如在32位SPARC体系下长度被限制。
内核还用到了其他一些不透明类型，包括dev_t、gid_t和uid_t等等。处理不透明类型时的原则是：
*不要假设该类型的长度。
*不要将该类型转化回其对应的C标准类型使用。
*编程时要保证在该类型实际存储空间和格式发生变化时代码不受影响。
3. 指定数据类型
内核中还有一些数据虽然无需用不透明的类型表示，但它们被定义成了指定的数据类型。jiffy数目和在中断控制时用到的flags参数就是两个例子，它们都应该被存放在unsigned long类型中。
当存放和处理这些特别的数据时，一定要搞清楚它们对应的类型后再使用。把它们存放在其他如unsigned int等类型中是一种常见错误。在32位机上这没什么问题，可是64位机上就会捅娄子了。
4. 长度明确的类型
作为一个程序员，你往往需要在程序中使用长度明确的数据。像操作硬件设备，进行网络通信和操作二进制文件时，通常都必须满足它们明确的内部要求。比如说，一块声卡可能用的是32位寄存器，一个网络包有一个16位字段，一个可执行文件有8位的cookie。在这些情况下，数据对应的类型应该长度明确。
内核在<asm/typs.h>中定义了这些长度明确的类型，而该文件又被包含在文件<linux/types.h>中。表2有完整的清单。
表2 长度明确的数据类型
| 类型 描 述 s8 带符号字节 u8 无符号字节 s16 带符号16位整数 u16 无符号16位整数 s32 带符号32位整数 u32 无符号32位整数 s64 带符号64位整数 u64 无符号64位整数 |
其中带符号的变量用的比较少。
这些长度明确的类型大部分都是通过typedef对标准的C类型进行映射得到的。在一个64位机上，它们看起来像：
typedef signed char s8;
typedef unsigned char u8;
typedef signed short s16;
typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef signed long s64;
typedef unsigned long u64;
而在32位机上，它们可能定义成：
typedef signed char s8;
typedef unsigned char u8;
typedef signed short s16;
typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef signed long long s64;
typedef unsigned long long u64;
上述的这些类型只能在内核内使用，不可以在用户空间出现（比如，在头文件中的某个用户可见结构中出现）。这个限制是为了保护命名空间。不过内核对应这些不可见变量同时也定义了对应的用户可见的变量类型，这些类型与上面类型所不同的是增加了两个下画线前缀。比如，无符号32位整形对应的用户空间可见类型就是__u32。该类型除了名字有区别外，与u32相同。在内核中你可以任意使用这两个名字，但是如果是用户可见的类型，那你必须使用下画线前缀的版本名，防止污染用户空间的命名空间。
5. char型的符号问题
C标准表示char类型可以带符号也可以不带符号，由具体的编译器、处理器或由它们两者共同决定到底char是带符号合适还是不带符号合适。
大部分体系结构上，char默认是带符号的，它可以自-128到127之间取值。而也有一些例外，比如ARM体系结构上，char就是不带符号的，它的取值范围是0～255
举例来说，在默认char不带符号，下面的代码实际会把255而不是-1赋予i：
char i = -1;
而另一种机器上，默认char带符号，就会确切地把-1赋予i。如果程序员本意是把－1保存在i中，那么前面的代码就该修改成：
signed char i = -1;
另外，如果程序员确实希望存储255，那么代码应该如下：
unsigned char = 255;
如果你在自己的代码中使用了char类型，那么你要保证在带符号和不带符号的情况下代码都没问题。如果你能明确要用的是哪一个，那么就直接声明它。