Почему POSIX поручил CHAR_BIT == 8?

Question

В обосновании POSIX есть примечание, что мандат CHAR_BIT равным 8 был уступкой, которая была необходима для поддержания выравнивания с C99 без выбрасывания сокетов / сетей, но я никогда не видел объяснения того, что именно был конфликт У кого-нибудь есть анекдоты или цитаты, почему это было сочтено необходимым?

Редактировать: Я получил много умозрительных ответов о том, почему желательно, чтобы CHAR_BIT было 8, и я согласен, но то, что я действительно ищу, это то, что технический конфликт между C99 и сетевые штучки в POSIX есть. Мое лучшее предположение состоит в том, что он как-то связан с C99, требующим, чтобы uint*_t был типом точного размера (без заполнения), тогда как inttypes.h ранее в POSIX такого требования не предъявлял.

Answer 1

Потому что подавляющее большинство стандартов (связанных со связью) из ANSI и ISO говорят в виде октетов (8-битных значений). Нет этой бессмысленной бессмысленной чепухи переменного размера: -)

И, поскольку довольно большое количество кода C использовало char или unsigned char для хранения и / или манипулирования этими значениями и предполагало, что они имеют ширину 8 битов, тот факт, что ISO допускает переменный размер, вызовет проблемы для этот код.

Помните одну из главных целей ISO C - существующий код важен, существующие реализации - нет. Это одна из причин, почему limits.h существует в первую очередь, а не просто принимает конкретные значения, потому что вокруг был код, который предполагал иначе.

POSIX также следовал тому же руководству. Предписав размер байта в 8 бит, они предотвратили взлом огромного количества кода уже в реальном мире.

Answer 2

Поскольку char - это наименьшая адресуемая единица в 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 на проводе, так как гораздо больше архитектур отличаются по порядку байтов, чем по размеру байта)

Answer 3

Мои догадки:

• Множество кода проходит через биты вроде

  for (int i = 0; i < 8; i++) { ... }
  

  и все, что может сломаться.

• Большинство других языков предполагают, что в любом случае это 8 бит, и они полностью сломались бы, если бы это было иначе

• Даже если бы большинство языков не требовало этого, большинство ABIвсе еще перерыв

• Это удобно в шестнадцатеричном формате (два куска): 0xAA

• Если вы начнете идти по этому маршруту, то вы можете начать думатьНу, кто сказал, что мы должны использовать биты с двумя состояниями?Почему бы не иметь Tristate бит?и т.д ... это только начинает становиться все менее и менее практичным.