5 ms·

> “In C or C++ you always have this fear that your code will just randomly explode,” says Mara Bos, cofounder of the drone firm Fusion Engineering and head of R

> “In C or C++ you always have this fear that your code will just randomly explode,” says Mara Bos, cofounder of the drone firm Fusion Engineering and head of Rust’s library team. That sounds like a completely valid reason to abandon C++ over Rust. I mean, what self-respecting programmer that keeps up to date with the trends would use a such a dangerous language that makes code blow up in their face? That is so '80s. Well, I am joking, of course, but that comment is hard to take seriously.

pjc50 4y ago
I can't follow which bits of this comment are supposed to be serious or joking, but: > use a such a dangerous language that makes code blow up in their face? There have simply been too many CVEs relating to memory safety in C and C++ software. It's not the 80s any more and we can't afford that.
- pclmulqdq 4y ago
  There are a lot of places where CVEs don't matter. The HFT firm I worked at groaned over Spectre and Meltdown mitigations, because now our CPUs will be slowed down by not using unsafe behavior. Similarly, I bet a lot of video game folks also didn't like them. If you aren't connecting to the network or running in any sort of privileged mode, the space of attacks that you need to care about is pretty limited. Ironically, the answer to a lot of unsafe input in Rust is to crash (if your error handling logic didn't catch it), which is something that you likely care about a lot. Most players care a lot less about corruption of the internal state of your video game than they do about crashes.
  - tiledjinn 4y ago
    Corruption of internal state is generally what leads to crashes. But yes, having worked in service games for over a decade now, clients are treated as untrusted agents regardless. CVEs that result in control over local execution are mostly not interesting. At least for the purpose of maintaining the game; platform holders _do_ care, mostly on fears of piracy. Galoob didn't cause revenue issues with Game Genie in the 90's. And revenue is the thing what matters.
  - krageon 4y ago
    You can disable such mitigations, which I'm struggling to credibly imagine inside a universe where an HFT firm (that is all about optimisation) would not know about.
    - pclmulqdq 4y ago
      The silicon did get slower due to a few mitigations, and in 2018, Intel was thinking about forcing a lot more of them on us in silicon (eg the equivalent of retpolines, but in silicon). The HFT industry and some HPC folks (and I assume some people from gaming) were involved in convincing Intel to keep those mitigations in software. EDIT: One fun fact here is that AMD never did the unsafe performance optimizations that Intel had to remove from their silicon. Spectre and Meltdown mitigations were instrumental in closing the gap between Intel and AMD.
VikingCoder 4y ago
Yes, in C or C++, code will just randomly explode. That's a completely accurate description. Once upon a time we had reports from our users that our software had deleted all of the files it could on their C:\ drive. Investigating, we found the code that caused it, something to the effect of: string rootDirectoryToDelete; // Set it reasonably: rootDirectoryToDelete = tempDirectoryWeMadeEarlier; Want to guess what happened? We had a mix of Emacs and Microsoft Visual Studio 6 developers, and somehow we ended up with a mix of carriage return / line feed in that source file. Both Emacs and the MSVS6 IDE showed those as three separate lines... but the MSVS6 compiler thought that the comment... had no terminator. So it took the assignment on the next line as just being part of the comment. You bet your ass I worry about code blowing up in my face. I write unit tests to try to protect myself. I can't tell you how many times whatever the "undefined behavior" was what the code depended on, and fixing it required some severe re-working. I also can't tell you how often someone thought "const" meant "completely immutable," and then they went on to accidentally modify what the const pointer was pointing at. Or how often I've had to fix someone else's race condition. Or how often a driver crash has clobbered me. I came across functionally like this in our code: int i = 2; int b = 3; printf("i = %d, b = %d\n", (i, b)); Want to guess what that does? (i, b) evaluates i, and then ignores it, and returns b. So it basically prints "i = 3, b = [core dump.]" The MSVS6 compiler gave a nice juicy warning on that line that everyone ignored. Yes, using the MSVS6 compiler was dumb, and ignoring the warnings was dumb, but guess what? I'm not in charge of how dumb my co-workers are, or how strict everyone's deadlines are, and bugs like this are actually kind of hard to find in a real code base with tons of problems going on. I'll take some more predictable behavior, if someone's offering it; yes, please.
- pclmulqdq 4y ago
  -Wall -Werror is your friend in C and C++ (even -Wextra sometimes). Zero-error policies are generally good. The spec in each language allows a lot of crazy undefined behavior. Conversely, the rust spec defines... nothing. Rust is specified as "whatever rustc does." That means the compiler is free to be arbitrary on this sort of thing. When there is a spec and there are competing implementations, there will be behavior divergence, and that will create these kinds of issues. Not having a spec can be a good thing.
rhn_mk1 4y ago
When you're working with software controlling lithium batteries, things literally blowing up in your face because of code mistakes are an actual concern. Things figuratively blowing up in your face are a concern even when not working on batteries.
Zagitta 4y ago
Take a look at this and you'll see it actually just randomly blows up :^) https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html https://kristerw.blogspot.com/2017/09/why-undefined-behavior...
- jenadine 4y ago
  Another "funny" one: https://www.reddit.com/r/cpp/comments/10yk8hk/ub_clang_decides_that_main_is_not_the_entry_point/ https://www.reddit.com/r/cpp/comments/10yk8hk/ub_clang_decid...
indigoabstract 4y ago
My point is, I find the whole C++ bashing bizarre. Not to mention the never-ending Rust evangelism. Rust is a good language and tracking memory access and ownership is something that's not always easy to do in C++, even with smart pointers. For some projects, like browsers, that's a big deal, for others, like games, not so much. But, it's not like you can't do dumb things in Rust. You can explode your code in any language you desire. Your skill is the only limit.
- dralley 4y ago
  >For some projects, like browsers, that's a big deal, for others, like games, not so much. Cheating in games is a big problem, and lots of money is spent addressing it, not to mention techniques which are barely distinct from spyware which cause performance reductions on the side. A lot of that cheating relies on bog standard memory bugs which game devs don't care about, apparently.
- Shish2k 4y ago
  > I find the whole C++ bashing bizarre. […] You can explode your code in any language you desire Some of us have spent decades working as sysadmins, getting woken up in the middle of the night to deal with whatever the latest CVE is... Do kids these days even know about codered, heartbleed, etc?

pjc50 4y ago

I can't follow which bits of this comment are supposed to be serious or joking, but: > use a such a dangerous language that makes code blow up in their face? There have simply been too many CVEs relating to memory safety in C and C++ software. It's not the 80s any more and we can't afford that.

pclmulqdq 4y ago
There are a lot of places where CVEs don't matter. The HFT firm I worked at groaned over Spectre and Meltdown mitigations, because now our CPUs will be slowed down by not using unsafe behavior. Similarly, I bet a lot of video game folks also didn't like them. If you aren't connecting to the network or running in any sort of privileged mode, the space of attacks that you need to care about is pretty limited. Ironically, the answer to a lot of unsafe input in Rust is to crash (if your error handling logic didn't catch it), which is something that you likely care about a lot. Most players care a lot less about corruption of the internal state of your video game than they do about crashes.
- tiledjinn 4y ago
  Corruption of internal state is generally what leads to crashes. But yes, having worked in service games for over a decade now, clients are treated as untrusted agents regardless. CVEs that result in control over local execution are mostly not interesting. At least for the purpose of maintaining the game; platform holders _do_ care, mostly on fears of piracy. Galoob didn't cause revenue issues with Game Genie in the 90's. And revenue is the thing what matters.
- krageon 4y ago
  You can disable such mitigations, which I'm struggling to credibly imagine inside a universe where an HFT firm (that is all about optimisation) would not know about.
  - pclmulqdq 4y ago
    The silicon did get slower due to a few mitigations, and in 2018, Intel was thinking about forcing a lot more of them on us in silicon (eg the equivalent of retpolines, but in silicon). The HFT industry and some HPC folks (and I assume some people from gaming) were involved in convincing Intel to keep those mitigations in software. EDIT: One fun fact here is that AMD never did the unsafe performance optimizations that Intel had to remove from their silicon. Spectre and Meltdown mitigations were instrumental in closing the gap between Intel and AMD.

VikingCoder 4y ago

Yes, in C or C++, code will just randomly explode. That's a completely accurate description. Once upon a time we had reports from our users that our software had deleted all of the files it could on their C:\ drive. Investigating, we found the code that caused it, something to the effect of: string rootDirectoryToDelete; // Set it reasonably: rootDirectoryToDelete = tempDirectoryWeMadeEarlier; Want to guess what happened? We had a mix of Emacs and Microsoft Visual Studio 6 developers, and somehow we ended up with a mix of carriage return / line feed in that source file. Both Emacs and the MSVS6 IDE showed those as three separate lines... but the MSVS6 compiler thought that the comment... had no terminator. So it took the assignment on the next line as just being part of the comment. You bet your ass I worry about code blowing up in my face. I write unit tests to try to protect myself. I can't tell you how many times whatever the "undefined behavior" was what the code depended on, and fixing it required some severe re-working. I also can't tell you how often someone thought "const" meant "completely immutable," and then they went on to accidentally modify what the const pointer was pointing at. Or how often I've had to fix someone else's race condition. Or how often a driver crash has clobbered me. I came across functionally like this in our code: int i = 2; int b = 3; printf("i = %d, b = %d\n", (i, b)); Want to guess what that does? (i, b) evaluates i, and then ignores it, and returns b. So it basically prints "i = 3, b = [core dump.]" The MSVS6 compiler gave a nice juicy warning on that line that everyone ignored. Yes, using the MSVS6 compiler was dumb, and ignoring the warnings was dumb, but guess what? I'm not in charge of how dumb my co-workers are, or how strict everyone's deadlines are, and bugs like this are actually kind of hard to find in a real code base with tons of problems going on. I'll take some more predictable behavior, if someone's offering it; yes, please.

pclmulqdq 4y ago
-Wall -Werror is your friend in C and C++ (even -Wextra sometimes). Zero-error policies are generally good. The spec in each language allows a lot of crazy undefined behavior. Conversely, the rust spec defines... nothing. Rust is specified as "whatever rustc does." That means the compiler is free to be arbitrary on this sort of thing. When there is a spec and there are competing implementations, there will be behavior divergence, and that will create these kinds of issues. Not having a spec can be a good thing.

rhn_mk1 4y ago

When you're working with software controlling lithium batteries, things literally blowing up in your face because of code mistakes are an actual concern. Things figuratively blowing up in your face are a concern even when not working on batteries.

Zagitta 4y ago

Take a look at this and you'll see it actually just randomly blows up :^) https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html https://kristerw.blogspot.com/2017/09/why-undefined-behavior...

jenadine 4y ago
Another "funny" one: https://www.reddit.com/r/cpp/comments/10yk8hk/ub_clang_decides_that_main_is_not_the_entry_point/ https://www.reddit.com/r/cpp/comments/10yk8hk/ub_clang_decid...

indigoabstract 4y ago

My point is, I find the whole C++ bashing bizarre. Not to mention the never-ending Rust evangelism. Rust is a good language and tracking memory access and ownership is something that's not always easy to do in C++, even with smart pointers. For some projects, like browsers, that's a big deal, for others, like games, not so much. But, it's not like you can't do dumb things in Rust. You can explode your code in any language you desire. Your skill is the only limit.

dralley 4y ago
>For some projects, like browsers, that's a big deal, for others, like games, not so much. Cheating in games is a big problem, and lots of money is spent addressing it, not to mention techniques which are barely distinct from spyware which cause performance reductions on the side. A lot of that cheating relies on bog standard memory bugs which game devs don't care about, apparently.
Shish2k 4y ago
> I find the whole C++ bashing bizarre. […] You can explode your code in any language you desire Some of us have spent decades working as sysadmins, getting woken up in the middle of the night to deal with whatever the latest CVE is... Do kids these days even know about codered, heartbleed, etc?