size_t против uintptr_t

Стандарт C гарантирует, что size_tэто тип, который может содержать любой индекс массива. Это означает, что, по логике, size_tдолжен быть в состоянии содержать любой тип указателя. Я читал на некоторых сайтах, которые я нашел на Google, что это законно и / или должно всегда работать:

void *v = malloc(10);
size_t s = (size_t) v;

Итак , в C99, стандарт введены intptr_tи uintptr_tтипы, которые подписали и беззнаковых типов гарантированно быть в состоянии держать указатели:

uintptr_t p = (size_t) v;

Так в чем же разница между использованием size_tи uintptr_t? Оба без знака, и оба должны быть в состоянии содержать любой тип указателя, поэтому они кажутся функционально идентичными. Есть ли реальная веская причина для использования uintptr_t(или, что еще лучше, a void *), а не a size_t, кроме ясности? В непрозрачной структуре, где поле будет обрабатываться только внутренними функциями, есть ли причина не делать этого?

Точно так же ptrdiff_tбыл подписанный тип, способный содержать различия в указателях и, следовательно, способный удерживать практически любой указатель, так чем он отличается от intptr_t?

Разве все эти типы не обслуживают тривиально разные версии одной и той же функции? Если нет, то почему? Что я не могу сделать с одним из них, что я не могу сделать с другим? Если так, то почему C99 добавил в язык два по существу лишних типа?

Я готов не обращать внимания на указатели функций, поскольку они не относятся к текущей проблеме, но не стесняйтесь упоминать их, так как у меня есть скрытое подозрение, что они будут центральными для «правильного» ответа.

size_tтип, который может содержать любой индекс массива Это означает, что, по логике, size_t должен содержать любой указатель

Не обязательно! Вернемся к дням сегментированных 16-битных архитектур, например: массив может быть ограничен одним сегментом (так будет 16-битный size_t), НО вы можете иметь несколько сегментов (поэтому intptr_tдля выбора потребуется 32-битный тип) сегмент, а также смещение в нем). Я знаю, что эти вещи звучат странно в наши дни несегментированных архитектур с единой адресацией, но стандарт ДОЛЖЕН обслуживать более широкий спектр, чем «что нормально в 2009 году», вы знаете! -)

По поводу вашего заявления:

«Стандарт C гарантирует, что size_tэто тип, который может содержать любой индекс массива. Это означает, что, логически, size_tдолжен быть в состоянии содержать любой тип указателя».

Это на самом деле заблуждение (заблуждение из-за неправильных рассуждений) ^(а) . Вы можете подумать, что последнее следует из первого, но на самом деле это не так.

Указатели и индексы массивов - это не одно и то же. Вполне правдоподобно предусмотреть соответствующую реализацию, которая ограничивает массивы 65536 элементами, но позволяет указателям обращаться к любому значению в массивном 128-битном адресном пространстве.

C99 утверждает, что верхний предел size_tпеременной определяется, SIZE_MAXи это может быть как 65535 (см. C99 TR3, 7.18.3, без изменений в C11). Указатели были бы довольно ограничены, если бы они были ограничены этим диапазоном в современных системах.

На практике вы, вероятно, обнаружите, что ваше предположение верно, но это не потому, что стандарт гарантирует это. Потому что на самом деле это не гарантирует.

^(а) Кстати, это не какая-то личная атака, а просто заявление о том, почему ваши высказывания ошибочны в контексте критического мышления. Например, следующие рассуждения также недействительны:

Все щенки милые. Эта штука милая. Поэтому эта вещь должна быть щенком.

Симпатичность или иное отношение к щенкам здесь не имеет отношения, все, что я утверждаю, это то, что два факта не приводят к выводу, потому что первые два предложения допускают существование милых вещей, которые не являются щенками.

Это похоже на ваше первое утверждение, не обязательно обязательное второе.

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

Разве простой разницы в именах недостаточно, чтобы использовать правильный тип для правильной вещи?

Если вы храните размер, используйте size_t. Если вы храните указатель, используйте intptr_t. Человек, читающий ваш код, мгновенно узнает, что «ага, это размер чего-то, возможно, в байтах», и «о, вот значение указателя, по какой-то причине сохраняемое как целое число».

В противном случае, вы можете просто использовать unsigned long(или, в наши современные времена unsigned long long) для всего. Размер - это еще не все, имена типов несут смысл, что полезно, поскольку помогает описать программу.

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

Хотя они обычно не используются на настольных компьютерах, стандарт C предназначен для поддержки даже небольших специализированных архитектур. Например, все еще разрабатываются встроенные системы с 8- или 16-битными процессорами.

Я хотел бы представить (и это относится ко всем именам типов), что он лучше передает ваши намерения в коде.

Например, даже если unsigned shortи wchar_tимеют тот же размер на Windows (я думаю), используя wchar_tвместо unsigned shortпоказывает намерение , что вы будете использовать его для хранения широкого характера, а не просто каким - то произвольное числа.

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

Так что, как бы все ни было улажено, нам пока нужно не так много типов.

Но даже в LP64, довольно распространенной парадигме, нам нужны size_t и ssize_t для интерфейса системных вызовов. Можно представить себе более ограниченную унаследованную или будущую систему, где использование полного 64-разрядного типа обходится дорого, и они могут захотеть использовать операции ввода-вывода объемом более 4 ГБ, но при этом все еще имеют 64-разрядные указатели.

Я думаю, вы должны задаться вопросом: что могло бы быть разработано, что может произойти в будущем. (Возможно, 128-битные указатели для распределенной системы через Интернет, но не более 64 бит в системном вызове, или, возможно, даже «устаревшее» 32-битное ограничение. :-) Представьте, что унаследованные системы могут получить новые компиляторы C .. ,

Кроме того, посмотрите на то, что существовало тогда. Помимо моделей памяти реального времени zillion 286, как насчет мэйнфреймов CDC с 60-битным словом / 18-битным указателем? Как насчет серии Cray? Не берите в голову нормальные ILP64, LP64, LLP64. (Я всегда думал, что Microsoft - это претенциозно с LLP64, это должен был быть P64.) Я, конечно, могу представить комитет, пытающийся охватить все основы ...

int main(){
  int a[4]={0,1,5,3};
  int a0 = a[0];
  int a1 = *(a+1);
  int a2 = *(2+a);
  int a3 = 3[a];
  return a2;
}

Подразумевается, что intptr_t всегда должен заменять size_t и наоборот.