在POSIX的基本原理中有一个注意事项,强制CHAR_BIT为8是一个让步,以保持与C99的对齐而不抛弃套接字/网络,但我从来没有看到冲突究竟是什么的解释.有没有人有轶事或引用为什么它被认为是必要的？
编辑:我已经得到了很多关于为什么它CHAR_BIT成为8的原因的猜测答案,我同意,但我真正想要的是C99与POSIX中的网络技术之间的技术冲突是什么.我最好的猜测是它与C99有关,要求uint*_t是精确大小的类型(没有填充),而inttypes.h之前在POSIX中没有提出这样的要求.
pax*_*blo 11
因为ANSI和ISO中的绝大多数标准(与通信相关)都以八位字节(8位值)的方式进行对话.没有那个多变的可变大小的字符废话:-)
并且,由于使用了相当大量的C代码char或unsigned char用于存储和/或操作这些值,并假设它们是8位宽,因此ISO允许可变大小的事实将导致该代码出现问题.
记住ISO C的一个重要目标 - 现有代码很重要,现有实现则不然.这是为什么limits.h首先存在而不是仅仅假设特定值的一个原因,因为存在其他假设的代码.
POSIX也遵循同样的指导方针.通过强制使用8位的字节大小,它们可以防止现实世界中已有的大量代码被破坏.
因为charC是C中最小的可寻址单元,如果你char大于8位,那么编写套接字实现将很困难或不可能,正如你所说的那样.网络都在CHAR_BIT == 8机器上运行.那么,如果你要从一台机器发送一条消息CHAR_BIT == 9到一台机器CHAR_BIT == 8,那么套接字库的附加位是什么？这个问题没有合理的答案.如果你截断了这个位,那么就很难指定一个像套接字代码客户端那样简单的东西 - "它是一个字符串数组,但你只能使用前8位"在这样的系统上是不合理的.而且,从8位系统到9位也会出现同样的问题 - 套接字系统与额外的位有什么关系呢？如果它将该位设置为零,想象一下那些int接通线路的人会发生什么.您必须在9位机器上进行各种令人讨厌的位掩码才能使其正常工作.
最后,由于99.9%的机器使用8位字符,因此并不是那么大的限制.大多数使用的计算机CHAR_BIT != 8也没有虚拟内存,无论如何都会将它们排除在POSIX兼容性之外.
当你在一台机器上运行时(正如标准C所假设的那样),你可以做一些CHAR_BIT不可知的事情,因为可能正在阅读或写入数据的双方都会对正在发生的事情达成一致.当您介绍类似套接字的东西时,涉及多台机器,它们必须就字符大小和字节序等内容达成一致.(尽管如此,Endinanness几乎只是对Big Endian的标准化,因为更多的架构在字节序上的区别与字节大小不同)