Parce qu' char est la plus petite unité adressable en C, si vous avez fait char de plus de 8 bits, il serait difficile, voire impossible, d'écrire une implémentation, comme vous l'avez dit. Les réseaux fonctionnent toutes sur CHAR_BIT == 8 des machines. Donc, si vous envoyez un message à partir d'une machine où l' CHAR_BIT == 9 à une machine où l' CHAR_BIT == 8, qu'est-ce que la bibliothèque des sockets à voir avec le bit supplémentaire? Il n'y a pas de réponse raisonnable à cette question. Si vous tronquez le peu, puis il devient difficile de spécifier même quelque chose d'aussi simple comme un tampon pour le client de les sockets code: "C'est un tableau de char, mais vous ne pouvez utiliser que les 8 premiers bits" serait déraisonnable sur un tel système. En outre, passant de 8 bits des systèmes à 9 bits serait le même problème -- quels sont les sockets système de le faire avec un peu plus? Si elle établit que les bits à zéro, imaginez ce qui arrive à quelqu'un qui met un int sur le fil. Que vous avez à faire toutes sortes de mauvaises bitmasking sur les 9 bits de la machine pour le faire fonctionner correctement.
Enfin, étant donné que 99,9% des machines 8 bits de caractères, il n'est pas tout que d'une limitation. La plupart des machines qui utilisent CHAR_BIT != 8 n'ont pas de mémoire virtuelle, ce qui permettrait d'exclure de la compatibilité POSIX de toute façon.
Lorsque vous êtes en cours d'exécution sur un seul ordinateur (standard C suppose), vous pouvez faire des choses comme être CHAR_BIT agnostique, parce que les deux côtés de ce qui pourrait être la lecture ou l'écriture des données d'accord sur ce qu'il se passe. Lorsque vous introduisez quelque chose comme sockets, où plus d'une machine sont concernés, ils DOIVENT s'entendre sur des choses comme la taille des caractères et l'endianness. (Endinanness est à peu près juste normalisé pour Big Endian sur le fil, si, comme beaucoup d'autres architectures diffèrent sur l'endianness qu'ils font sur la taille en octets)
