Как именно гарантируется выделения n байт памяти библиотекой stdint.h?

Question

[70-C9-4E-54-03-2F]

Стало интересно, как именно реализуются типы переменных вроде int8_t, int16_t и прочие, входящие в состав стандартной библиотеки stdint.h в языке С. Модификаторы типа вроде long или short не гарантируют увеличение или сокращение выделяемой памяти под переменную, а результат зависит от компилятора, - так пишется во многих учебниках. В то же время типы intx_t, описанные в библиотеке stdint.h, якобы гарантируют размер переменной. Однако зайдя в исходный код библиотеки, единственное, что я смог понять, это то, что каждый тип просто является альтернативным названием для обычных типов: int16_t = short, int8_t = char и т.д. Вопрос заключается в том, каким образом гарантируется выделение фиксированного размера переменной, если изнутри все те же short и long? Компилятор = gcc от mingw, а ОС windows (если это как-то поможет объяснить).
Спасибо

Comments

[shurshur]

Так стандартные заголовки и идут свои в каждом компиляторе, поэтому тут нет никакого противоречия.

Answer 1

[Mercury13]

В моей версии MinGW это сделано так.
На уровне компилятора определяется макрос __INT64_TYPE__, который на данных настройках значит long long. Затем через жёсткую препроцессорную магию определяются и остальные типы и константы, связанные с int64.

# include_next <stdint.h>  // то есть самого себя!

. . .

#ifdef __INT64_TYPE__
# ifndef __int8_t_defined /* glibc sys/types.h also defines int64_t*/
typedef __INT64_TYPE__ int64_t;
# endif /* __int8_t_defined */
typedef __UINT64_TYPE__ uint64_t;
# undef __int_least64_t
# define __int_least64_t int64_t
# undef __uint_least64_t
# define __uint_least64_t uint64_t
# undef __int_least32_t
# define __int_least32_t int64_t
# undef __uint_least32_t
# define __uint_least32_t uint64_t
# undef __int_least16_t
# define __int_least16_t int64_t
# undef __uint_least16_t
# define __uint_least16_t uint64_t
# undef __int_least8_t
# define __int_least8_t int64_t
# undef __uint_least8_t
# define __uint_least8_t uint64_t
#endif /* __INT64_TYPE__ */

Полагаю, это связано с тем, что компилятор и библиотека сильно кроссплатформенны и написаны в большом отрыве друг от друга. Решай мы более простую задачу — то есть связку «компилятор-библиотека» для конкретной ОС — можно было просто
typedef long long int64_t;

Answer 2

[res2001]

В Си, да и в С++, стандартные целочисленные типы, поддерживаемые компилятором - это char, short, int, long long и их беззнаковые братья. Стандарт действительно не фиксирует размеры стандартных целочисленных типов. Это сделано потому что стандарт описывает абстрактный язык, который должен компилироваться для разных платформ.

Компилятор же компилирует программу под конкретную платформу с конкретными соглашениями по типам. Ему заведомо известны размеры стандартных типов на данной конкретной платформе. Стандартная библиотека так же обычно пишется под конкретный компилятор и конкретную платформу.
Так что (u)intX_t - это всегда define над стандартными типами. И ничего странного в этом нет.

Answer 3

[Vindicar]

Не претендую на глубокое знание плюсов, но...

Модификаторы типа вроде long или short не гарантируют увеличение или сокращение выделяемой памяти под переменную, а результат зависит от компилятора, - так пишется во многих учебниках. В то же время типы intx_t, описанные в библиотеке stdint.h, якобы гарантируют размер переменной.

Но ведь stdint.h идёт в комплекте с компилятором, а потому составлен с учётом особенностей этого компилятора.