go - 为什么 unsafe.Sizeof 返回一个 uintptr？

Question

根据文档(https://golang.org/pkg/unsafe/#Sizeof)unsafe.Sizeof返回给定表达式的大小(以字节为单位)。理想情况下，任何给定表达式的大小都可以用 uint32 表示。或 uint64 .那为什么 Golang 返回一个 uintptr反而？这不是很困惑吗？一个 uintptr应该保存一个指向某个数据值的指针，但在这种情况下，它实际上不是一个指针，它只是一个数字，对吗？

Answer 1

评论中有很多很好的答案，归结为“因为它足够大，但又不太大”。不过，我认为从历史的角度来看这可能会有所帮助，特别注意这一切是如何在 C 编程语言中发生的。
在非常古老的(准标准)C 中，如果您及时回溯，甚至没有明确的 unsigned整数类型。 PDP-11 具有:

char , 8 位，有符号；

int , 16 位，有符号；和

指针，16 位，无符号。

那是:

int i;
int *u;

你是如何制作两个整数的， i正在签名，和 u未签名。设置 i到 32767 (0x7fff) 然后增加它给你 -32768 (0x8000)，它逐渐增加到 -1 (0xffff) 然后为零。设置 u到 32767，然后增加它给你 32768，逐渐增加到 65535，然后翻转到零。
整数和指针之间缺乏区别意味着设备驱动程序可以读取:

struct {
    int csr;
    int blk;
    int bar;
    int bcr;
};

0177440->bcr = count;
0177440->blk = block;
0177440->bar = addr;
0177440->csr = READ | GO;

这可能就是告诉设备读取一些字节或 block 的方式。
(这也是为什么结构成员名称，如 st_ino 中的 struct stat 都使用这样的前缀: st_ino 只是表示“一些整数偏移量”，您可以将 st_ino 成员与任何指针一起使用，甚至使用一个普通变量。前缀意味着您可以 #include 多个 header 而不会使其结构成员名称发生冲突。)
当 C 语言在 32 位和其他机器上工作时，所有这些都变得站不住脚了。 C 增长了 unsigned整数类型，而不是将指针作为无符号整数压入服务，Steve Johnson 的 PCC 编译器转为 unsigned变成一个修饰符，可以应用于 char和 short以及 int .进行了大量的实验。最终，在 1989 年，C 首次使用我们现在拥有的大部分语法和语义进行了标准化(尽管新标准添加了新类型和许多函数，等等)。
一些早期的 C 先驱者参与了 Go 的创建，尤其受到 Ken Thompson 的影响。 .维基百科页面上有一个合适的引用:

When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason.

正如我们在早期的 C 语言中所看到的，作为整数的指针是一种合适的无符号类型，它不仅可以保存任何指针，而且如果被视为无符号，还可以保存任何对象大小。当然，作为整数的指针不能直接用作指针，并且对于 GC 系统和并发性，我们需要语言本身具有指针。但是我们还需要能够为语言编写运行时支持，1 我们需要整数化指针，这也涵盖了我们对对象大小的所有需求。因此，编译器内置的一种类型涵盖了所有需求。即 as simple as possible, but no simpler .

1我说“我们”，好像我与它有任何关系。很明显，一旦您实现了一些运行时系统。