卷曲是c - 不是铁锈

偶尔有人向我暗示，如果用“安全语言”重写curl和libcurl会更好。 Rust是一种通常建议的替代语言。当我们发布新的安全漏洞时，这种情况尤其经常发生。 （更新：我认为Rust是一种很好的语言！这篇文章和我在这里的立场与我对Rust或其他语言的看法无关，无论是否安全。）

卷曲代码准则要求我们坚持使用C89将任何代码接受到存储库中。 C89（有时也称为C90）–最早的ANSI C标准。古老而保守。

这一事实使项目，公司和人员可以使用基本上任何已知的操作系统以及您能想到的任何CPU体系结构（至少在32位或更大的情况下）将卷入事物。没有其他编程语言可以如此广泛地使用，并且可以轻松地用于所有内容。这使curl成为最便携的项目之一，并且是curl成功的部分解释。

curl项目也始于90年代，甚至比您建议的大多数其他替代语言还早存在。哎呀，对于一个真正稳定的项目来说，使用一种还没有足够老的语言来上学就没有责任。

也许不再是正确的了，但至少C的知识非常广泛，在这种情况下，作为当前现有的替代语言，可以肯定的是，它们的听众或掌握这些语言的人员更狭窄。

用用更好地设计为“安全”的现代语言编写相同的代码，用C编写安全代码是否需要更多的谨慎和更多的“技巧”？是的，它确实。但是，我们已经完成了大部分工作，并且保持这一水平并不困难或麻烦。

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

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

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

项目很容易添加对用C编写的库的依赖关系，因为这是编写操作系统和系统库的方法，至今仍在2017年。这是默认设置。每个人都可以构建和安装此类库，它们会被使用，并且人们知道它们的工作方式。

使用另一种语言的库会将这种语言（以及编译器，调试器以及用该语言编写的libcurl所需的任何依赖项）添加为当今大量用C或C ++编写的项目的新依赖项。在许多情况下，这些项目将完全忽略并拒绝以“替代语言”编写的项目。

在curl项目中，我们故意保持保守，并遵循旧标准，以确保每个人都可以使用的可行且可靠的库。现在和可预见的将来。 15年前在卷曲中起作用的东西至今仍然可以使用。以同样的方式。用户可以依靠卷曲。我们坚持。我们不会对现代趋势反应迟钝。我们仍然坐在船上。我们不会摇滚。

显然，这也不关乎语言，而是关乎简单的旧软件工程：将curl转换或重写为新语言会引入很多错误。我们今天没有的错误。

更不用说重写将花费巨大的精力和大量的时间。如今，这些精力可以花在进一步改善卷曲度上。

如果我今天开始这个项目，我会选择其他语言吗？ 可能是。 也许不吧。 如果内存安全和相关问题是我最关心的问题，那么可以肯定。 但是，正如我上面提到的，还有其他一些问题，所以这实际上取决于我的优先级。 归根结底，剩下的问题是：我们将获得比所支付的更多的收益，并且在哪个时间范围内？ 谁会赢，谁会输？ 我敢肯定会有，甚至可能已经存在，curl和libcurl的竞争对手，以及用这些新的替代语言中的大多数编写的有效替代方法。 其中一些绝对是非常好的，并且会被使用并赢得名声和荣耀。 其中一些会胡扯。 就像软件始终在工作一样。 让一千个卷曲的竞争对手绽放！ 将来会在某些时候重写curl吗？ 我不会排除它，但是我发现它不太可能。 我发现它在短期内或未来几年内不会发生的可能性更大。