junkun

肯定是失败的，按照兼容性和可移植性来说，肯定应该使用绝对值。比如二进制文件就得用 int64 ，后来的 java 能够跨平台也是不同平台的大小是一致的。就算架构使用的位数不同，使用绝对值也可以更好地模拟，就算是 10 位机，也可以用 int10 来模拟 int8 ，int20 来模拟 int16 ，但是 C/C++这样就更可能出问题。

如果按每个平台的特性来说，定义几种特殊类型就够了，比如 ifast 和 usize ，现在这样连 char ，short 和 long 标准定义上都没有固定的长度就太扯淡了。使用特殊类型也能更方便地检索出这里是平台相关的代码，而不是像 C/C++这样默认全都是平台相关的，只有写 intXX_t 才是平台无关的。

@nlzy 但是更恶劣的是那个 maintainer 说 "And I also do not want another maintainer." 这个 another 是否包含 C 开发者呢。https://lore.kernel.org/rust-for-linux/[email protected]/

意思是这个模块只有他能改吗。感觉这个已经不是 r4l 的问题，而是 linux 这个项目有问题了，linus 是“仁慈的独裁者”，然后下面的 maintainer 个个也有样学样要当独裁者吗？

@majula 不是引用新接口的问题，是如果别人用了某个接口，上游的人改之前需不需要跟别人沟通。如果上游自顾自地改了一个接口，然后下游的东西全挂了，上游还觉得无所谓。我觉得挺糟糕的。
何况这个人的态度就像是，如果你依赖我的接口，我就改给你看。
https://vt.social/@lina/113045455229442533 还有别的开发者反馈，因为是 rust 开发者，所以提交 C 语言部分的 patches 就被故意拒绝。

IPv4 分配很不合理，早期很多公司、学校就占了一个巨大的公网网段，现在其实都还是空闲的。

有一个问题是 std::string 的实现不确定也不那么稳定，不同 libcpp 的 string 都叫 std::string ，glibcpp 还改过 std::string 的内部实现。

@echo1937 甚至不同公司、不同项目用的 C++都不相似。

C++20 可以用 std::span 。

@CloveAndCurrant rust 的 error 是支持 traceback 的