锈会卷曲吗？

用Rust重写程序已经有些模棱两可了，已经讨论很多的程序就是cURL。

人们第一次建议用Rust重写cURL时，主要作者Daniel Stenberg撰写了一篇文章，说明为什么cURL是用C编写的，而不会用Rust重写。它包括以下部分：

那里。一个简单的事实是，我们过去的大多数漏洞都是由于代码中的逻辑错误而发生的。逻辑错误并非真正受语言限制，不能仅通过更改语言来解决。

当然，如果使用其他语言，则可能会避免一些问题。缓冲区溢出，两次释放和越界读取等，但是由于使用C编写curl，我们的大部分安全问题并未发生。

三年后，有消息传出一些Rust代码将在cURL中使用，尽管只是作为可选的HTTP后端-它不是完全重写。这则新闻重新引发了讨论（Reddit，Hacker News）。似乎有些人仍然认为可以编写内存安全的C，并且根据上面的引用，cURL是内存安全的C！

很容易找出来。 cURL作者拥有大量（已知）cURL安全漏洞。如果略读一下，很明显，不，cURL具有大量的内存安全性错误。由于有一个不错的清单，其中包含每个错误的详尽描述，因此这似乎是衡量Rust可以阻止多少错误的好机会。

我认为“这将防止多少历史性错误”是判断编程语言或功能的一种非常好的方法。例如，这项出色的研究表明，使用Typescript可以预防典型的Javascript代码中大约15％的错误。很难用这样的证据来反对静态类型。

我遍历了cURL安全问题的整个列表，并对所有错误进行了分类，以及我认为Rust是否会阻止它们。我没有查看所有代码（例如，如果它说``缓冲区溢出''，那么很明显Rust会阻止它），因此只需一小撮盐就可以得出这些结果。欢迎更正！

47是标准内存错误（溢出，释放后使用等）。 Rust肯定会阻止这些情况。作为比较，谷歌发现70％的Chrome错误是内存错误。

5是整数溢出，Rust在释放模式下默认情况下不会阻止（尽管可以通过可选标志），但是它们会导致内存错误，但确实可以防止。

1是由于滥用fgets（）。 Rust不会阻止您使API变得难以使用，但可以肯定地减少了机会，例如通过警告您是否不使用结果。很难想象Rust会发生此错误。

否不可能可能是是0 25 50 75 100错误计数Rust是否会阻止该错误？其余的错误是某种逻辑错误。肯定有几种Rust应该帮不上忙的“我们应该检查但没有”。但是，还有很多其他的错误来自cURL，它们对几乎所有内容都进行了临时的按字符逐行字符解析，而在Rust中，您可能会使用库来完全解析事物。在我的理货中，我已经慷慨地将其视为“否”，但我怀疑使用Rust的可能性较小。

可以肯定地说，没有人可以编写内存安全的C语言，甚至没有使用所有工具的著名程序员。这是Daniel在2017年：

我们会使用静态代码分析器定期扫描卷曲代码（我们保持“零覆盖率”问题策略为零），并使用valgrind和地址清理程序运行测试套件。

自该声明以来，cURL的安全性问题中有15个中有12个是内存错误（或整数溢出导致内存错误）。 锈的拥护者似乎过于热情，我认为这引起了人们的轻微反响，他们认为“铁锈肯定不会那么好； 这些人必须像特朗普的支持者或基督徒一样是迷惑的狂热者。” 但是很难用这样的数字来争论。 其中一些错误确实很复杂。 人们错过了他们，这一点也不奇怪。 只有自动化工具才能检测或阻止这些情况。 cURL试图重用连接，并声明不应这样做，这是大量的错误（约9个）。 这些是我对错误进行分类的方式。 如果我遇到了严重错误，请告诉我。