4 ms·

> You see, I relied on a high-quality 3rd party XML parser, and that parser had a handful of bugs. At that point it's hardly the fault of C. Even in supposedly

> You see, I relied on a high-quality 3rd party XML parser, and that parser had a handful of bugs. At that point it's hardly the fault of C. Even in supposedly "memory safe" languages like Java, XML (and json) parsers are often riddled with bugs and design problems that can be exploited for remote execution. It's a joke, but these parsers are still somehow considered "best in class" because many supposed "programmers" are willing to trade security for the ability to write annotations. I'd say that what you describe in your software is exactly what i like about C. You know it's dangerous, so you take precautions. You then discover that those precautions maybe aren't enough and you go looking for something more stringent (like rust). There's learning there. If we cargo cult Rust as "what people should learn instead of C because it's secure" bad programmers will go write poorly designed rust code that's as unsafe (if not more so) as any C code, except now they won't be careful because "the language is safe".

kajaktum 4y ago
>I'd say that what you describe in your software is exactly what i like about C. You know it's dangerous, so you take precautions. You then discover that those precautions maybe aren't enough and you go looking for something more stringent (like rust). There's learning there. If we cargo cult Rust as "what people should learn instead of C because it's secure" bad programmers will go write poorly designed rust code that's as unsafe (if not more so) as any C code, except now they won't be careful because "the language is safe". What level of cope is this? "Bad language is better because we know its bad so we become better!" Every time someone argues for C or C++ I replace them with assembly and C respectively. The argument makes about the same amount of sense.
- lumb63 4y ago
  I don’t think that’s what they’re saying. They’re saying that there is utility in understanding what you’re getting with a memory-safe language like Rust. Why would a programmer care if they’re getting memory safety and thread safety if they don’t know what unsafeness looks like? It’s the same reason we teach history in school; knowing where we came from gives us a better perspective of where we are today.
  - avgcorrection 4y ago
    They can read the Rustonomicon. Done. They can also write C or Unsafe Rust in order to learn about what regular Rust gives them. But none of that is an argument for learning C and then stumbling into a safer language after doing that, since then you have to learn (say) Rust as well as unlearn your C (or whatever unsafe language habits) as well.[1] [1] https://www.reddit.com/r/rust/comments/10rnymj/my_reaction_to_dr_stroustrups_recent_memory/j6ydjso/ https://www.reddit.com/r/rust/comments/10rnymj/my_reaction_t...
  - kajaktum 4y ago
    >It’s the same reason we teach history in school; knowing where we came from gives us a better perspective of where we are today. What we learn from history is mostly "holy shit that was fucking awful thank god we stopped doing that!". Except for programmers it seems. I have no objection to learning or using C but we don't ride horse caravans around anymore.
ekidd 4y ago
> Even in supposedly "memory safe" languages like Java, XML (and json) parsers are often riddled with bugs and design problems that can be exploited for remote execution. Why do we think this is OK, even for a moment? For how many decades will we accept massive vulnerabilities everywhere? We can't rewrite everything, but why isn't Chrome's "Rule of Two" a minimum professional standard for new code? This isn't just a Rust thing. For example, why don't more languages allow me to say, "This XML parser is forbidden from talking to the network or file system"? Why could log4j load code without being granted special permission?
- lanstin 4y ago
  I think there is an opportunity here for language design. I should be able to import a library and mark it as nothing but computation, or as network only no file system, or file system only but no network, and have the language itself enforce that guarantee. I believe it has to be at the language/compilation level as executable segments can always just trap into the OS. If there were some syntax, then you could even specify the particular network endpoints or file system paths allowed. It is sort of old fashioned, a sort of dynamic scoping of access context, but would be better than you call a shared library which starts up some threads with network connections all invisible to you. There would be some idea of the main function and spawning threads or green threads would also need to specify what that thread can do, a subset of what the creating thread can do.
  - PaulDavisThe1st 4y ago
    > I should be able to import a library and mark it as nothing but computation, or as network only no file system, or file system only but no network, and have the language itself enforce that guarantee. There is no sheriff to enforce this guarantee. There's nobody come to save you (us) from ourselves. You can try to build walls around things, but meanwhile other people are building ladders (or digging tunnels). It gets worse though. Virtuality, whether via literal VMs or COWbuilder-style containers, means that defining what is means to access certain resources is hard to do. For the most part, this resolves nicely (i.e. you almost always have less significant access to "the real world" than you might believe), but it's not trivial to determine.
nicoburns 4y ago
> Even in supposedly "memory safe" languages like Java, XML (and json) parsers are often riddled with bugs and design problems that can be exploited for remote execution The huge benefit of having a strict compiler like Rust's is that it massively raises the quality floor for every single library in the ecosystem. This is especially true if a library doesn't use unsafe (which is true of many Rust libraries including the most popular XML library https://lib.rs/crates/quick-xml https://lib.rs/crates/quick-xml). > bad programmers will go write poorly designed rust code that's as unsafe (if not more so) as any C code, except now they won't be careful because "the language is safe". The whole point of the language being safe is that you can't write code as bad as C code (e.g. contained RCE vulnerabilities) without going massively out of your way by using an `unsafe` block or doing something obviously stupid like passing an unsanitised string to `exec`. It won't compile. I would absolutely trust carelessly coded safe Rust code over carefully coded C (unless that carefulness is taken to the extreme as in MISRA-C or similar).

kajaktum 4y ago

>I'd say that what you describe in your software is exactly what i like about C. You know it's dangerous, so you take precautions. You then discover that those precautions maybe aren't enough and you go looking for something more stringent (like rust). There's learning there. If we cargo cult Rust as "what people should learn instead of C because it's secure" bad programmers will go write poorly designed rust code that's as unsafe (if not more so) as any C code, except now they won't be careful because "the language is safe". What level of cope is this? "Bad language is better because we know its bad so we become better!" Every time someone argues for C or C++ I replace them with assembly and C respectively. The argument makes about the same amount of sense.

lumb63 4y ago
I don’t think that’s what they’re saying. They’re saying that there is utility in understanding what you’re getting with a memory-safe language like Rust. Why would a programmer care if they’re getting memory safety and thread safety if they don’t know what unsafeness looks like? It’s the same reason we teach history in school; knowing where we came from gives us a better perspective of where we are today.
- avgcorrection 4y ago
  They can read the Rustonomicon. Done. They can also write C or Unsafe Rust in order to learn about what regular Rust gives them. But none of that is an argument for learning C and then stumbling into a safer language after doing that, since then you have to learn (say) Rust as well as unlearn your C (or whatever unsafe language habits) as well.[1] [1] https://www.reddit.com/r/rust/comments/10rnymj/my_reaction_to_dr_stroustrups_recent_memory/j6ydjso/ https://www.reddit.com/r/rust/comments/10rnymj/my_reaction_t...
- kajaktum 4y ago
  >It’s the same reason we teach history in school; knowing where we came from gives us a better perspective of where we are today. What we learn from history is mostly "holy shit that was fucking awful thank god we stopped doing that!". Except for programmers it seems. I have no objection to learning or using C but we don't ride horse caravans around anymore.

ekidd 4y ago

> Even in supposedly "memory safe" languages like Java, XML (and json) parsers are often riddled with bugs and design problems that can be exploited for remote execution. Why do we think this is OK, even for a moment? For how many decades will we accept massive vulnerabilities everywhere? We can't rewrite everything, but why isn't Chrome's "Rule of Two" a minimum professional standard for new code? This isn't just a Rust thing. For example, why don't more languages allow me to say, "This XML parser is forbidden from talking to the network or file system"? Why could log4j load code without being granted special permission?

lanstin 4y ago
I think there is an opportunity here for language design. I should be able to import a library and mark it as nothing but computation, or as network only no file system, or file system only but no network, and have the language itself enforce that guarantee. I believe it has to be at the language/compilation level as executable segments can always just trap into the OS. If there were some syntax, then you could even specify the particular network endpoints or file system paths allowed. It is sort of old fashioned, a sort of dynamic scoping of access context, but would be better than you call a shared library which starts up some threads with network connections all invisible to you. There would be some idea of the main function and spawning threads or green threads would also need to specify what that thread can do, a subset of what the creating thread can do.
- PaulDavisThe1st 4y ago
  > I should be able to import a library and mark it as nothing but computation, or as network only no file system, or file system only but no network, and have the language itself enforce that guarantee. There is no sheriff to enforce this guarantee. There's nobody come to save you (us) from ourselves. You can try to build walls around things, but meanwhile other people are building ladders (or digging tunnels). It gets worse though. Virtuality, whether via literal VMs or COWbuilder-style containers, means that defining what is means to access certain resources is hard to do. For the most part, this resolves nicely (i.e. you almost always have less significant access to "the real world" than you might believe), but it's not trivial to determine.

nicoburns 4y ago

> Even in supposedly "memory safe" languages like Java, XML (and json) parsers are often riddled with bugs and design problems that can be exploited for remote execution The huge benefit of having a strict compiler like Rust's is that it massively raises the quality floor for every single library in the ecosystem. This is especially true if a library doesn't use unsafe (which is true of many Rust libraries including the most popular XML library https://lib.rs/crates/quick-xml https://lib.rs/crates/quick-xml). > bad programmers will go write poorly designed rust code that's as unsafe (if not more so) as any C code, except now they won't be careful because "the language is safe". The whole point of the language being safe is that you can't write code as bad as C code (e.g. contained RCE vulnerabilities) without going massively out of your way by using an `unsafe` block or doing something obviously stupid like passing an unsanitised string to `exec`. It won't compile. I would absolutely trust carelessly coded safe Rust code over carefully coded C (unless that carefulness is taken to the extreme as in MISRA-C or similar).