Почему мандат POSIX CHAR_BIT == 8?

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

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

Ответ 1

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

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

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

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

Ответ 2

Поскольку char - наименьшая адресуемая единица в C, если вы сделали char больше 8 бит, было бы сложно или невозможно записать реализацию сокетов, как вы сказали. Сети работают на машинах CHAR_BIT == 8. Итак, если вы должны отправить сообщение с машины, где CHAR_BIT == 9, на машину, где CHAR_BIT == 8, что такое библиотека сокетов для дополнительного бита? Нет разумного ответа на этот вопрос. Если вы усекаете бит, тогда становится трудно указать даже что-то столь же простое, как буфер для клиента кода сокетов - "Это массив char, но вы можете использовать только первые 8 бит", было бы необоснованным на таких система. Более того, переход от 8-битных систем до 9 бит будет такой же проблемой - что система сокетов делает с этим дополнительным битом? Если он устанавливает этот бит в ноль, представьте, что произойдет с тем, кто ставит int на провод. Вам нужно будет делать всевозможные неприятные битмаски на 9-битной машине, чтобы заставить ее работать правильно.

Наконец, поскольку 99,9% машин используют 8-битные символы, это не все, что отличает ограничение. Большинство машин, которые используют CHAR_BIT != 8, также не имеют виртуальной памяти, что в любом случае исключало бы их из совместимости с POSIX.

Когда вы работаете на одной машине (как предполагает стандарт C), вы можете делать такие вещи, как be CHAR_BIT agnostic, потому что обе стороны того, что можно читать или записывать данные, согласуются с тем, что происходит. Когда вы вводите что-то вроде сокетов, в которых задействовано более одной машины, они ДОЛЖНЫ согласовать такие вещи, как размер персонажа и сущность. (Endinanness в значительной степени просто стандартизирована для Big Endian на проводе, тем не менее, поскольку многие другие архитектуры различаются по контенту, чем размер байта)

Ответ 3

Мои догадки:

Много кода проходит через такие биты, как
```
for (int i = 0; i < 8; i++) { ... }
```
и все, что сломается.
Большинство других языков принимают в любом случае 8 бит, и они полностью сломаются, если в противном случае
Даже если большинство языков этого не требовали, большинство ABI все равно нарушат
Он удобен в шестнадцатеричном (два куска): 0xAA
Если вы начнете идти по этому маршруту, тогда вы можете начать думать: "Ну, кто говорит, что мы должны использовать биты с двумя состояниями? Почему бы не иметь тристатные биты? и т.д.... он начинает становиться все менее и менее практичным.