Size_t портативный?

Question

GCC 4.4.1, C99

Я использую size_t, а также size_t является unsigned int. Анкет Тем не менее, это зависит от того, используете ли вы 32 -битный или 64 бит.

Я буду использовать size_t хранить размер буфера.

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

Просто вопрос с использованием size_t На 32 или 64 бит. Какие ситуации вызовут самую серьезную проблему?

Answer 1

size_t Гарантированно сможет удерживать количество байтов любого объекта в вашей реализации. Вот почему тип возврата sizeof является size_t.

Так что да, это портативно.

Answer 2

Как говорили другие, size_t правильный и вполне приемлем для хранения результата sizeof() или размер любого представительного объекта в байтах. Вы должны следить за следующим:

1. size_t тот же размер, что и какой -то непознанный целочисленный тип. Анкет Это не обязательно такое же количество байтов, что и самый большой тип без знака, unsigned int, unsigned long, так далее.
2. sizeof(size_t) является определенным внедрением числа байтов, поэтому memcpy', или присваивание любого целочисленного типа, кроме как uintmax_t плохая идея. Я даже не уверен, что можно с уверенностью предположить, что он одинаково или меньше, чем uintmax_t.
3. Написание а size_t значение для двоичного файла и чтение его обратно в size_t Другим процессом, на другой машине или чем -то, скомпилированным с различными вариантами компилятора, может быть опасным для вашего здоровья.
4. Отправка size_t ценность в сети и попытка получить ее с помощью sizeof(size_t) Буфер на другой стороне довольно небезопасен.

Все это стандартные проблемы с любым другим целым типом, кроме unsigned char. Анкет Так size_t так же портативно, как и любой другой целочисленный тип.

Answer 3

Имеет смысл использовать size_t или ssize_t для буфера, если вы используете malloc () или read (). Для портативности используйте size_max, ssize_max, sizeof (type-in-buffer) и %zd или %zu printf ().

Answer 4

Вы также получили OFF_T и PTRDIFF_T / SSIZE_T, которые различаются между архитектурами таким же образом.

Если вы используете их правильно, то они портативны по архитектурам. В 32-битной системе все они будут иметь ширину 32 бита, а в 64-битной системе все они будут иметь ширину 64 бита. Это то, что вы хотите-размер буфера не может быть более крупным, чем 32-битный размер_T в 32-битной системе, но он может быть намного больше в 64-битной системе.

Вы никогда не должны использовать INT, Longs или что -то еще. Помимо чего-либо еще, размер длиной варьируется в зависимости от платформы (32 бита на большинстве 32-битных систем, 64-битные на 64-битные системы UNIX, 32-битные на 64-битные окна).

Answer 5

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

Тип size_t имеет очень конкретную цель. Он может удерживать размер любого объекта в данной реализации. Т.е. это тип, который всегда может получить результат sizeof() оператор. Тип size_t не имеет никакой другой цели, и в рамках предполагаемого приложения оно на 100% портативно, столь же портативно, насколько это может быть что угодно.

Каким «портативным» вы спрашиваете, это еще раз, не ясно.

Answer 6

Вы не должны предполагать, что size_t - это без знака Int (Смотрите этот ответ), но я думаю, что он имеет одинаковый диапазон на обеих архитектурах.

Answer 7

Зависит от того, для чего вы используете size_t.

Если вы используете его, чтобы определить размер буфера памяти, он будет безопасным, поскольку size_t достаточно большой, чтобы решить всю память любого компьютера. Так что, если буфер памяти больше этого, у вас все равно есть проблема.

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

Answer 8

Единственная настоящая серьезная проблема с этим - это попытка получить доступ к довольно большому массиву или большому количеству для size_t.

Точно так же, как просто обычного «int» может быть достаточно на 64-битной, но может вызвать аварию на 32-битной, потому что он слишком большой для INT в 32-битной системе.