如题，今天给 C 库写其他语言 binding 的时候想到的。
论据 1：C/C++ 之后，几乎所有语言都 (1) 定死了各个整数类型的宽度（如 Java ），或者 (2) 换用定宽类型（例如 i64 、u32 、int64 、usize ）。即使 C 自己也引入了 int64_t 这样的固定宽度类型。
论据 2：非常不利于编写可移植的库。比如用两个不同编译器编译出的代码，虽然函数声明一样，但因为一边 long 是 64 位整数，另一边是 32 位整数，导致不能互相调用。
论据 3：不确定宽度导致程序员不得不随时检查数值范围，一旦疏忽（例如，换了新平台或者编译器）很容易造成溢出问题。为了检查，编写大量含宏代码，给程序员带来额外心智负担。
论据 4：使数值类型系统变得过于复杂，很多场景下并不需要严格区分 long long 、long 、int 、short 、char 。但程序员由于认识不清楚而随意使用，反而可能造成 linter 不能正确给出 warning 。
---
这个 int 、long 不定宽的规定是当时随意决定的吗？还是刻意设计出来的？为什么直到今天还有大量 C 库、接口仍在使用这样的类型？（例如 POSIX 、libc 、OpenMP ）
论据 1：C/C++ 之后，几乎所有语言都 (1) 定死了各个整数类型的宽度（如 Java ），或者 (2) 换用定宽类型（例如 i64 、u32 、int64 、usize ）。即使 C 自己也引入了 int64_t 这样的固定宽度类型。
论据 2：非常不利于编写可移植的库。比如用两个不同编译器编译出的代码，虽然函数声明一样，但因为一边 long 是 64 位整数，另一边是 32 位整数，导致不能互相调用。
论据 3：不确定宽度导致程序员不得不随时检查数值范围，一旦疏忽（例如，换了新平台或者编译器）很容易造成溢出问题。为了检查，编写大量含宏代码，给程序员带来额外心智负担。
论据 4：使数值类型系统变得过于复杂，很多场景下并不需要严格区分 long long 、long 、int 、short 、char 。但程序员由于认识不清楚而随意使用，反而可能造成 linter 不能正确给出 warning 。
---
这个 int 、long 不定宽的规定是当时随意决定的吗？还是刻意设计出来的？为什么直到今天还有大量 C 库、接口仍在使用这样的类型？（例如 POSIX 、libc 、OpenMP ）
1
Select Language