5 ms·
> I'm quite bored by the obsession of some for replacing C. Well, I'm quite bored of the endless stream of memory safety vulnerabilities that can be systematic
by moosingin3space 9y ago
> I'm quite bored by the obsession of some for replacing C.
Well, I'm quite bored of the endless stream of memory safety vulnerabilities that can be systematically eliminated with memory-safe languages like Rust. Note that every single one of the CVEs disclosed yesterday in dnsmasq are memory safety violations, and the fact that buffer overflows, data races, and other related errors are not only pervasive, but also tend to sit around for years in codebases[1].
> Nobody would criticize assembly for letting you shoot yourself in the foot, C is much the same.
It's completely acceptable to criticize the choice of any tool. I can and do criticize the use of C for any code that touches a network and in some cases consider it willful negligence, as using a non-memory-safe language to parse untrusted data is asking for trouble.
[1]: https://twitter.com/johnregehr/status/914663997647069184 https://twitter.com/johnregehr/status/914663997647069184
- tempodox 9y agoWhen you speak of “parsing untrusted data”, do you mean to imply that “parsing trusted data” even exists? I for one would view any and all input as untrusted.
- moosingin3space 9y ago"Trusted data" can exist in theory -- on a closed network where you control all endpoints -- but does not exist in practice (as many devices eventually connect to the Internet or exchange data with Internet-connected computers). Therefore, it follows that re-writing parsers in memory-safe languages would provide a nice bang-for-buck.
- TheCoelacanth 9y agoIn some cases, say the parser for an interpreter for a general purpose programming language, I would consider the data "trusted". You are already allowing execution of arbitrary code, so there is nothing to be gained by exploiting the parser.