¿Por qué POSIX ordenó CHAR_BIT== 8?

(3)

Hay una nota en el razonamiento de POSIX de que exigir que CHAR_BIT sea 8 fue una concesión que fue necesaria para mantener la alineación con C99 sin desechar sockets / redes, pero nunca he visto la explicación de qué fue exactamente el conflicto. ¿Alguien tiene anécdotas o citas de por qué se consideró necesario?

Edit: He recibido muchas respuestas especulativas sobre por qué es deseable que CHAR_BIT tenga 8, y estoy de acuerdo, pero lo que realmente estoy buscando es cuál es el conflicto técnico entre C99 y las cosas de red en POSIX. Mi mejor conjetura es que tiene algo que ver con que C99 requiere que uint*_t sean tipos de tamaño exacto (sin relleno) mientras que inttypes.h anteriormente en POSIX no hizo tal requisito.

Debido a que char es la unidad direccionable más pequeña en C, si char un char más de 8 bits, sería difícil o imposible escribir una implementación de sockets, como dijiste. Todas las redes se ejecutan en máquinas CHAR_BIT == 8 . Entonces, si tuviera que enviar un mensaje desde una máquina donde CHAR_BIT == 9 a una máquina donde CHAR_BIT == 8 , ¿qué debe hacer la biblioteca de sockets con el bit extra? No hay una respuesta razonable a esa pregunta. Si trunca el bit, entonces es difícil especificar incluso algo tan simple como un búfer para el cliente del código de sockets: "Es una matriz de caracteres, pero solo puede usar los primeros 8 bits" no sería razonable en un sistema así. . Además, pasar de sistemas de 8 bits a 9 bits sería el mismo problema: ¿qué relación tiene el sistema de tomas con ese bit adicional? Si establece ese bit a cero, imagine lo que le sucede a alguien que pone un int en el cable. Tendría que hacer todo tipo de detecciones de bits desagradables en la máquina de 9 bits para que funcione correctamente.

Finalmente, dado que el 99.9% de las máquinas usan caracteres de 8 bits, no es una gran limitación. La mayoría de las máquinas que usan CHAR_BIT != 8 tampoco tienen memoria virtual, lo que las excluiría de la compatibilidad con POSIX de todos modos.

Cuando se ejecuta en una sola máquina (como se supone en C estándar), puede hacer cosas como ser CHAR_BIT agnóstico, porque ambos lados de lo que podría estar leyendo o escribiendo datos están de acuerdo con lo que está sucediendo. Cuando introduces algo como enchufes, donde está involucrada más de una máquina, DEBEN ponerse de acuerdo sobre aspectos como el tamaño del personaje y la permanencia. (Sin embargo, Endinanness está prácticamente estandarizado a Big Endian en el cable, ya que muchas más arquitecturas difieren en endianness que en tamaño de byte)

Debido a que la gran mayoría de los estándares (relacionados con la comunicación) de ANSI e ISO hablan en términos de octetos (valores de 8 bits). No hay ninguna de esas tonterías de caracteres de tamaño variable:

Y, dado que una cantidad bastante grande de código C usaba char o unsigned char para almacenar y / o manipular estos valores, y suponía que tenían 8 bits de ancho, el hecho de que ISO permitiera un tamaño variable causaría problemas para ese código.

Recuerde uno de los objetivos principales de ISO C: el código existente es importante, las implementaciones existentes no lo son. Esta es una razón por la cual limits.h existe, en primer lugar, en lugar de simplemente asumir valores específicos, porque había un código que suponía lo contrario.

POSIX también siguió esa misma pauta. Al exigir un tamaño de bytes de 8 bits, impidieron la rotura de una gran cantidad de código ya en el mundo real.

Mis conjeturas:

Mucho código pasa por bits como
for (int i = 0; i < 8; i++) { ... }
Y todo eso se rompería.
La mayoría de los otros idiomas suponen que es de 8 bits de todos modos, y se romperían por completo si no fuera
Incluso si la mayoría de los idiomas no requirieran esto, la mayoría de los ABI se romperían
Es útil en hexadecimal (dos mordiscos): 0xAA
Si comienzas a seguir esa ruta, entonces podrías comenzar a pensar: Bueno, ¿quién dice que tenemos que usar bits de 2 estados? ¿Por qué no tener bits tristate? etc ... simplemente comienza a ser cada vez menos práctico.