Какие-либо размеры гарантированного минимума для типов в C?

Это описано в статье Википедии :

short int не должен быть больше, чем int .
int не должен быть больше, чем long int .

short int должен иметь длину не менее 16 бит.
int должен иметь длину не менее 16 бит.
long int должен иметь длину не менее 32 бита.
Длина long long int должна быть не менее 64 бита.

Стандарт не требует, чтобы какие-либо из этих размеров обязательно были разными. Это совершенно верно, например, если все четыре типа имеют длину 64 бита.

Да, значения в float.h и limits.h зависят от системы. Вы никогда не должны делать предположений о ширине шрифта, но стандарт устанавливает некоторые минимумы. См. §6.2.5 и §5.2.4.2.1 в стандарте C99 .

Например, в стандарте только сказано, что char должен быть достаточно большим, чтобы вместить каждый символ в наборе символов исполнения. Он не говорит о его ширине.

Для случая с плавающей запятой стандарт намекает на порядок, в котором даны ширины типов:

§6.2.5.10

Есть три вещественные плавающие типы , обозначенные как float , double и long двойной . ³²⁾ Набор значений типа float является подмножеством набора значений типа double ; набор значений типа double является подмножеством набора значений типа long double .

Они неявно определяют, который шире другого, но не конкретно насколько они широки. «Подмножество» само по себе расплывчато, потому что long double может иметь точно такой же диапазон double и удовлетворять этому пункту.

Это довольно типично для C, и многое остается для каждой отдельной среды. Вы не можете предположить, вы должны спросить компилятор.

Однако новый C99 определяет (в stdint.h ) необязательные типы минимальных размеров, например uint_least8_t , int_least32_t и так далее ..
(см. en_wikipedia_Stdint_h )

Если вы не хотите проверять размер (кратное знакам) любого типа в вашей системе / платформе, действительно соответствует вашему ожидаемому размеру, вы можете сделать:

enum CHECK_FLOAT_IS_4_CHARS
{
   IF_THIS_FAILS_FLOAT_IS_NOT_4_CHARS = 1/(sizeof(float) == 4)
};

Большинство библиотек определяют что-то вроде этого:

#ifdef MY_ARCHITECTURE_1
typedef unsigned char u_int8_t;
typedef short int16_t;
typedef unsigned short u_int16_t;
typedef int int32_t;
typedef unsigned int u_int32_t;
typedef unsigned char u_char;
typedef unsigned int u_int;
typedef unsigned long u_long;
typedef unsigned short u_short;
#endif

вы можете затем использовать эти typedef в своих программах вместо стандартных типов.

Часто разработчики, задающие вопросы такого рода, имеют дело с упорядочением упакованной структуры в соответствии с определенным макетом памяти (как для протокола сообщений) . Предполагается, что язык должен напрямую определять размещение 16-, 24-, 32-битных и т.д. полей для этой цели.

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

1236] Фактически, язык C не предназначался для конкретной аппаратной реализации. Это было определено в целом, чтобы разработчик компилятора C мог должным образом адаптироваться к реалиям конкретного процессора. Аппаратная архитектура Франкенштейна, состоящая из 9-битных байтов, 54-битных слов и 72-битных адресов памяти, легко и недвусмысленно отображается на функции C. ( char - 9 бит; short int , int и long int - 54 бита.)

Это общая причина, почему спецификация C говорит что-то вроде "не надо"

Текущая реальность - и, кажется, будущее - такова, что программное обеспечение требует, чтобы архитектура обеспечивала 8-битные байты и чтобы слова памяти были адресованы как отдельные байты. Так было не всегда. Не так давно я работал над архитектурой CDC Cyber, которая имеет 6-битные «байты» и 60-битные слова. Было бы интересно реализовать AC на этом. Фактически, эта архитектура отвечает за странную семантику упаковки Паскаля - если кто-нибудь это помнит.

Текущая реальность - и, кажется, будущее - такова, что программное обеспечение требует, чтобы архитектура обеспечивала 8-битные байты и чтобы слова памяти были адресованы как отдельные байты. Так было не всегда. Не так давно я работал над архитектурой CDC Cyber, которая имеет 6-битные «байты» и 60-битные слова. Было бы интересно реализовать AC на этом. Фактически, эта архитектура отвечает за странную семантику упаковки Паскаля - если кто-нибудь это помнит.

Цитирование стандарта дает то, что определено как «правильный ответ», но не на самом деле не отражает общий способ написания программ.

Люди все время делают предположения, что char - это 8 бит, short - 16, int - 32, long равно 32 или 64, а long long равно 64.

Эти предположения - не лучшая идея, но вас не уволят за их выполнение.

Теоретически может использоваться для указания типов с фиксированной битовой шириной, но вам нужно найти один для Microsoft. ( См. Здесь MS stdint.h .) Одна из проблем здесь состоит в том, что C ++ технически нуждается только в совместимости с C89, чтобы быть соответствующей реализацией; даже для простого C C99 не поддерживается полностью даже в 2009 году.

Также неверно сказать, что для char нет спецификации ширины. Да, в стандарте просто не говорится, подписан он или нет. Вот что на самом деле говорит C99:

• количество бит для наименьшего объекта, который не является битовым полем (байт)
  CHAR_BIT 8
  
• минимальное значение для объекта типа signed char
  SCHAR_MIN -127 // - (2 ⁷ - 1)
  
• максимальное значение для объекта типа signed char
  SCHAR_MAX +127 // 2 ⁷ - 1
  
• максимальное значение для объект типа unsigned char
  UCHAR_MAX 255 // 2 ⁸ - 1