size_t 与 uintptr_t

size_t 是一种可以保存任何数组索引的类型。这意味着，从逻辑上讲， size_t 应该能够保存任何指针类型

不必要！回到分段 16 位架构的时代，例如：一个数组可能仅限于一个段（所以 16 位 size_t 可以）但是你可以有多个段（所以一个 32 位 intptr_t type 需要选择段以及其中的偏移量）。我知道在这些统一可寻址的未分段架构的时代，这些事情听起来很奇怪，但标准必须满足比“2009 年的正常情况”更广泛的变化，你知道的！-)

---

关于你的说法：

“C 标准保证 size_t 是一种可以保存任何数组索引的类型。这意味着，从逻辑上讲，size_t 应该能够保存任何指针类型。”

这实际上是一个谬误（由不正确的推理导致的误解）（a）。您可能认为后者是从前者继承而来的，但事实并非如此。

指针和数组索引不是一回事。设想一个将数组限制为 65536 个元素但允许指针将任何值寻址到巨大的 128 位地址空间的一致实现是相当合理的。

C99 声明 size_t 变量的上限由 SIZE_MAX 定义，可以低至 65535（参见 C99 TR3, 7.18.3，在 C11 中未更改）。如果指针在现代系统中被限制在这个范围内，那么指针将是相当有限的。

在实践中，您可能会发现您的假设成立，但这并不是因为标准保证了这一点。因为它实际上并不能保证它。

(a) 顺便说一句，这不是某种形式的人身攻击，只是说明为什么你的陈述在批判性思维的背景下是错误的。例如，下面的推理也是无效的：

所有的小狗都很可爱。这东西很可爱。所以这东西一定是小狗。

小狗的可爱与否在这里无关紧要，我只是说这两个事实并不能得出结论，因为前两句话允许存在不是小狗的可爱事物。

这类似于您的第一个声明，不一定要求第二个。

---

关于分段限制、奇异架构等的推理，我将让所有其他答案为自己辩护。

名称上的简单差异还不足以为正确的事物使用正确的类型吗？

如果要存储大小，请使用 size_t。如果要存储指针，请使用 intptr_t。阅读您的代码的人会立即知道“啊哈，这是某物的大小，可能以字节为单位”，以及“哦，这是一个指针值，由于某种原因被存储为整数”。

否则，您可以只使用 unsigned long（或者，在现代，unsigned long long）来处理所有事情。大小不是一切，类型名称具有有用的含义，因为它有助于描述程序。

---

最大数组的大小可能小于指针。考虑分段架构 - 指针可能是 32 位，但单个段可能只能寻址 64KB（例如旧的实模式 8086 架构）。

虽然这些在桌面机器中不再常用，但 C 标准旨在支持甚至小型的专用架构。例如，仍然有使用 8 位或 16 位 CPU 开发的嵌入式系统。

---

我会想象（这适用于所有类型名称）它可以更好地传达您在代码中的意图。

例如，即使在 Windows 上 unsigned short 和 wchar_t 大小相同（我认为），使用 wchar_t 而不是 unsigned short 表明您将使用它来存储宽字符，而不仅仅是一些任意数。

---

向后和向前看，并回想各种奇怪的架构散布在景观中，我很确定他们试图包装所有现有系统并提供所有可能的未来系统。

可以肯定的是，事情解决的方式，到目前为止，我们需要的类型并不多。

但即使在 LP64（一个相当常见的范例）中，我们也需要 size_t 和 ssize_t 作为系统调用接口。可以想象一个更受限制的遗留系统或未来系统，其中使用完整的 64 位类型是昂贵的，并且他们可能希望在大于 4GB 但仍具有 64 位指针的 I/O 操作上投入使用。

我想你必须想知道：可能已经开发了什么，未来可能会发生什么。 （也许是 128 位分布式系统互联网范围的指针，但在系统调用中不超过 64 位，或者甚至可能是“遗留”的 32 位限制。:-) 遗留系统可能会获得新的 C 编译器的图像.. .

另外，看看当时存在的东西。除了数以万计的 286 个实模式内存模型，CDC 60 位字/18 位指针大型机又如何呢？克雷系列怎么样？没关系正常的 ILP64、LP64、LLP64。 （我一直认为微软在 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 ，反之亦然。

---