13 ms·

Another counterexample to the idea that modern C++ written by experts is free of memory safety issues.

deleted 10y ago
[deleted]
mememachine 10y ago
If the solution doesnt make it any easier to avoid memory issues (just forces you to avoid them,) its not an attractive solution
- gcp 10y ago
  Given that we're talking about bugs, I don't think this is a valid argument. Being forced to avoid bugs is good, yes? Even if it's not necessarily less hard to make them in the first place (which is arguable, too!). I mean, I spend most of my time coding searching for bugs, not avoiding them.
- pcwalton 10y ago
  I disagree? It's better to not have memory safety problems than to have them!
- amalag 10y ago
  Avoiding bugs is a pretty effective way to not have bugs.
  - mlmlmasd 10y ago
    Avoiding bugs is the default in software development in any language, no? If you have pointer DSL that can lead to various bugs, replacing it with a more complex pointer DSL is not a good way to avoid bugs. And I don't think C++ 'smart pointers' and other crap are very simple (relative to C pointers) or much less error-prone. That's just my opinion though.
    - marvy 10y ago
      Avoiding bugs is what you try to do by default in any language, yes. But success is not guaranteed :) I agree that in general, if you have a pointer DSL that can lead to bugs, replacing to with a more complex one just makes things worse, assuming all else stays the same. But! Maybe the extra complexity buys you something. For instance, maybe the complexity allows the compiler to prove that certain classes of bugs are impossible. Now we have a tradeoff. Let's say we want to get a correct program as fast as possible. Then you can quickly write a buggy program in the simple DSL, but you will need to spend some time debugging it. Or you can spend a long time wrestling with the complicated one, but you don't need to debug pointer issues anymore (you still have to fix other bugs of course.) Then the question is: do you save more time in debugging than you pay in "fighting" a complex language. And the answer is always the same: maybe! Maybe you make less pointer bugs in C than most people, and maybe you're more allergic to smart pointers than most people, so for you it's pointless. Certainly pointer bugs are not very rare in the world though. Worse, they're not always noticed right away.
  - civility 10y ago
    Turning off your computer is the only way to avoid bugs. All software has bugs.
    - pcwalton 10y ago
      We aren't talking about eliminating all bugs. We're talking about eliminating memory safety problems, which frequently result in RCE.
      - civility 10y ago
        What you were doing is advocating Rust in a C++ thread, again. Safety first, and all that. Congratulations on getting voted to the top of this topic, but it's tiresome. Let's pretend C++ is a car. I get in my car, and I drive somewhere. Yes, there are hundreds of thousands of accidents per year, but really, most people get where they want to go, and we aren't all dead. I've had my share of fender benders, but no RCE has ever been exploited in 25 years of my C or C++ code. Let's pretend Rust is a car. Half the time I want to go somewhere, I can't even get out of the driveway before I stumble into a limitation of the language or the standard libraries. One time it's overly strict coherence rules that forbid me from doing something that shouldn't break coherence [1]. Some other time it's because the standard library doesn't have a trait for a commonly implemented method, so I can't write a generic function to call that method. Yet another time, I find out you really can't accomplish the task without writing unsafe code, so the compiler really wasn't going to protect me from myself anyways [2]. So yeah, Rust is saving me from car accidents because I don't even make it to the road much less my destination half the time. Do you drive wearing a 5 point harness and a helmet? Do you really think a true expert couldn't make a safe C++ regex library? -- [1] Honestly, I think you guys are screwed on that one. I suspect you're going to have to break backwards compatibility to really fix it, so I believe you'll leave it broken instead. [2] Outside of FFI calls, I have no idea what rules I'm supposed to respect in an unsafe block. I guess I just can't drive my Rust car to that neighborhood then. Very safe indeed.
        dbaupp 10y ago
        > no RCE has ever been exploited in 25 years of my C or C++ code I'm genuinely curious about you say this with any sort of surety. Do you have any sort of, say, crash reporting from users' computer, or some other way to know if a problem occurred in the wild? (Not that these will actually detect a successful RCE, only failed ones.) Additionally, not being (known to be) exploited doesn't mean that much without more context, e.g. have malicious people/machines/fuzzers actually tried to find exploits in your code?
_delirium 10y ago
Not that I necessarily think it'd avoid the problem even then, but I wouldn't call this modern C++ exactly. For one thing, it's (c) 2002, so written in C++98. And for another, it looks very uh, C-ish (not that uncommon in the C++98 era). In the bad sense of lots of error-prone pointer-based string manipulation, stuff like this: if(STR_COMP(s1, p) >= 0) { do{ ++p; }while(*p); ++p; if(STR_COMP(s1, p) <= 0) return set_->isnot ? next : ++next; }
sidlls 10y ago
Well, yes if the strawman "all modern C++ written by experts is free from memory safety issues" is what you're countering. I find that to be gratuitous and petty, and not a good representation of Rust, however.
- 10293101 10y ago
  The position "modern C++ is safe and all C programmers are idiots" is repeated quite often here on HN. To be fair, it is always the same small group of people who do that.
  - sidlls 10y ago
    Not sure what that has to do with anything. The parent is a very vocal Rust proponent and made a ridiculous comment which has been called out by myself and several others. It hasn't anything to do with any "small group of people" talking smack about C programmers. Although that's unfortunate, too.
    - eridius 10y ago
      I don't think it's ridiculous. It seems like almost every discussion about Rust vs C++ here has a few people saying that you don't need Rust's guarantees about memory safety if you're writing modern C++. And that oft-repeated comment is what pcwalton is referencing.
      - blub 10y ago
        pcwalton is not framing the problem in a particularly useful way. This is a question of risk management and his argument is basically that one should always reduce the risk of memory management errors to zero. Others say that they can tolerate some risk, as long as it's in acceptable margins, since it's expensive to totally eliminate it. I don't think that lecturing everyone "No, you really want to have 0 risk, you fools" is a successful programming language advocacy strategy.
        10y ago
andrepd 10y ago
It's not modern, it's C++98.
stinos 10y ago
Do you have more of these examples?
- anon1385 10y ago
  http://www.cvedetails.com/vulnerability-list/vendor_id-452/product_id-3264/opmemc-1/Mozilla-Firefox.html http://www.cvedetails.com/vulnerability-list/vendor_id-452/p... http://www.cvedetails.com/vulnerability-list/vendor_id-452/product_id-3264/opec-1/Mozilla-Firefox.html http://www.cvedetails.com/vulnerability-list/vendor_id-452/p...
ambrop7 10y ago
If it has memory safety issues then it's not written by experts :)
- dbaupp 10y ago
  So there's no such thing as a C++ expert? That statement is dangerously close to a No True Scotsman: IME even people who seem to fit any reasonable definition of expert (committee members, compiler developers) still make memory-safety mistakes.
  - civility 10y ago
    > That statement is dangerously close to a No True Scotsman It also had a smiley in it. I'm pretty sure you missed the joke and don't realize you're preaching to the choir.
    - dbaupp 10y ago
      This is Poe's law territory, e.g. a lot of your own comments sound very similar to the parent, and there are other emoticons more commonly used to indicate sarcasm/joke.
      - civility 10y ago
        > This is Poe's law territory Heh, I think that's possibly the only virtue to sarcasm: it confuses the pedants. I use friendly smileys or the word "heh" when I'm trying to be jovial, and I'm willing to give that poster the benefit of the doubt. :-) > a lot of your own comments sound very similar to the parent Which comments? > there are other emoticons more commonly used to indicate sarcasm/joke I think any common standard about something like this probably only applies to a narrow clique.
ska 10y ago
Ignoring the straw man, can you explain how c++98 code provides a counterexample for anything in modern c++?
mackal 10y ago
This isn't modern c++, but whatever.
randyrand 10y ago
No, but not everything needs to be memory safe. That's what the kernel is there for. You can typically just restart the program. The classic program safety vs programmer time tradeoff.
- AaronFriel 10y ago
  If your program isn't memory safe, it's very often the case that someone can make your program run their program, at which point the kernel doesn't know that your program didn't intend to modify itself. W^X/NX bits and other technologies don't totally obviate the issue, as ROP gadgets can be used to defeat it. And so on, there's a whole domain of computer science dedicated to that arms race and no evidence that it's stopping any time soon. On the other hand, a Rust program without unsafe should simply never execute code outside of its defined control flow, it's not possible to hijack any control flow on the stack or heap, and so a running program under arbitrary user input can only ever explore execution paths that exist in the absence of memory unsafety. No ROP gadgets or heap/stack smashing, no overflows leading to overwriting a function definition in memory, no overwriting the parameters of a function to cause impossible branches to be taken, and so on.
  - cbhl 10y ago
    I recall that there was at least one shipping video game where "someone" was "my future self" -- they exploited a buffer overflow after-the-fact in a shipped video game (a EULA dialog?) in order to make it run an updater.
  - randyrand 10y ago
    Not every program is intended to be connected to the internet or have user provided input. I agree, for many programs memory safety matters. But there are a large chunk of programs where it doesnt matter/is not worth the effort.
    - msbarnett 10y ago
      > Not every program is intended to be connected to the internet or have user provided input. While true, I think the vast majority of programs do do one of these two things (and increasingly, both), whereas the majority of programmers seem to think that what they work on "isn't a security issue". It's this disconnect that is giving us the Internet of Crap. Your phone apps, your fridge, your video games, your text editor -- every program I interact with every day -- it's all a security issue
jasode 10y ago
Maybe you're right that it's wrong to think that modern C++17 (unique_ptr, shared_ptr) written by experts is free of memory safety issues. But in this specific case, it looks like old code from 2002[1]. No modern techniques such as std:unique_ptr. Just 1970s C style raw pointer manipulation. I suppose the contemporaneous compiler used by John Maddock would have been C++98?!? [1] one example of a source file mentioned by the bug report: http://www.boost.org/doc/libs/1_63_0/boost/regex/v4/perl_matcher.hpp http://www.boost.org/doc/libs/1_63_0/boost/regex/v4/perl_mat...
- dnljms 10y ago
  The main windows compiler would have been Visual C++ 6, which was released before standardization, and had notable differences from C++98. It was also buggy for non-trivial templates. Visual C++ 2002 wasn't much better.
acconsta 10y ago
> modern C++ This library is old enough to drive...
gok 10y ago
I don't fundamentally disagree with you (any C++ bigger than a screenful of code probably has memory safety issues) but contrary to its reputation, I've find Boost to be of really poor code quality.
- tonyedgecombe 10y ago
  I've find Boost to be of really poor code quality Which is telling because it's raison d'etre is quality and it was written by some pretty smart people.
flukus 10y ago
> modern C++ written by experts is free of memory safety issues Which simply isn't good enough, it takes 10+ years to become expert level at anything, so what are people supposed to do to get to that level?

deleted 10y ago

[deleted]

If the solution doesnt make it any easier to avoid memory issues (just forces you to avoid them,) its not an attractive solution

gcp 10y ago
Given that we're talking about bugs, I don't think this is a valid argument. Being forced to avoid bugs is good, yes? Even if it's not necessarily less hard to make them in the first place (which is arguable, too!). I mean, I spend most of my time coding searching for bugs, not avoiding them.
pcwalton 10y ago
I disagree? It's better to not have memory safety problems than to have them!
amalag 10y ago
Avoiding bugs is a pretty effective way to not have bugs.
- mlmlmasd 10y ago
  Avoiding bugs is the default in software development in any language, no? If you have pointer DSL that can lead to various bugs, replacing it with a more complex pointer DSL is not a good way to avoid bugs. And I don't think C++ 'smart pointers' and other crap are very simple (relative to C pointers) or much less error-prone. That's just my opinion though.
  - marvy 10y ago
    Avoiding bugs is what you try to do by default in any language, yes. But success is not guaranteed :) I agree that in general, if you have a pointer DSL that can lead to bugs, replacing to with a more complex one just makes things worse, assuming all else stays the same. But! Maybe the extra complexity buys you something. For instance, maybe the complexity allows the compiler to prove that certain classes of bugs are impossible. Now we have a tradeoff. Let's say we want to get a correct program as fast as possible. Then you can quickly write a buggy program in the simple DSL, but you will need to spend some time debugging it. Or you can spend a long time wrestling with the complicated one, but you don't need to debug pointer issues anymore (you still have to fix other bugs of course.) Then the question is: do you save more time in debugging than you pay in "fighting" a complex language. And the answer is always the same: maybe! Maybe you make less pointer bugs in C than most people, and maybe you're more allergic to smart pointers than most people, so for you it's pointless. Certainly pointer bugs are not very rare in the world though. Worse, they're not always noticed right away.
- civility 10y ago
  Turning off your computer is the only way to avoid bugs. All software has bugs.
  - pcwalton 10y ago
    We aren't talking about eliminating all bugs. We're talking about eliminating memory safety problems, which frequently result in RCE.
    - civility 10y ago
      What you were doing is advocating Rust in a C++ thread, again. Safety first, and all that. Congratulations on getting voted to the top of this topic, but it's tiresome. Let's pretend C++ is a car. I get in my car, and I drive somewhere. Yes, there are hundreds of thousands of accidents per year, but really, most people get where they want to go, and we aren't all dead. I've had my share of fender benders, but no RCE has ever been exploited in 25 years of my C or C++ code. Let's pretend Rust is a car. Half the time I want to go somewhere, I can't even get out of the driveway before I stumble into a limitation of the language or the standard libraries. One time it's overly strict coherence rules that forbid me from doing something that shouldn't break coherence [1]. Some other time it's because the standard library doesn't have a trait for a commonly implemented method, so I can't write a generic function to call that method. Yet another time, I find out you really can't accomplish the task without writing unsafe code, so the compiler really wasn't going to protect me from myself anyways [2]. So yeah, Rust is saving me from car accidents because I don't even make it to the road much less my destination half the time. Do you drive wearing a 5 point harness and a helmet? Do you really think a true expert couldn't make a safe C++ regex library? -- [1] Honestly, I think you guys are screwed on that one. I suspect you're going to have to break backwards compatibility to really fix it, so I believe you'll leave it broken instead. [2] Outside of FFI calls, I have no idea what rules I'm supposed to respect in an unsafe block. I guess I just can't drive my Rust car to that neighborhood then. Very safe indeed.
      - dbaupp 10y ago
        > no RCE has ever been exploited in 25 years of my C or C++ code I'm genuinely curious about you say this with any sort of surety. Do you have any sort of, say, crash reporting from users' computer, or some other way to know if a problem occurred in the wild? (Not that these will actually detect a successful RCE, only failed ones.) Additionally, not being (known to be) exploited doesn't mean that much without more context, e.g. have malicious people/machines/fuzzers actually tried to find exploits in your code?

_delirium 10y ago

Not that I necessarily think it'd avoid the problem even then, but I wouldn't call this modern C++ exactly. For one thing, it's (c) 2002, so written in C++98. And for another, it looks very uh, C-ish (not that uncommon in the C++98 era). In the bad sense of lots of error-prone pointer-based string manipulation, stuff like this: if(STR_COMP(s1, p) >= 0) { do{ ++p; }while(*p); ++p; if(STR_COMP(s1, p) <= 0) return set_->isnot ? next : ++next; }

sidlls 10y ago

Well, yes if the strawman "all modern C++ written by experts is free from memory safety issues" is what you're countering. I find that to be gratuitous and petty, and not a good representation of Rust, however.

10293101 10y ago
The position "modern C++ is safe and all C programmers are idiots" is repeated quite often here on HN. To be fair, it is always the same small group of people who do that.
- sidlls 10y ago
  Not sure what that has to do with anything. The parent is a very vocal Rust proponent and made a ridiculous comment which has been called out by myself and several others. It hasn't anything to do with any "small group of people" talking smack about C programmers. Although that's unfortunate, too.
  - eridius 10y ago
    I don't think it's ridiculous. It seems like almost every discussion about Rust vs C++ here has a few people saying that you don't need Rust's guarantees about memory safety if you're writing modern C++. And that oft-repeated comment is what pcwalton is referencing.
    - blub 10y ago
      pcwalton is not framing the problem in a particularly useful way. This is a question of risk management and his argument is basically that one should always reduce the risk of memory management errors to zero. Others say that they can tolerate some risk, as long as it's in acceptable margins, since it's expensive to totally eliminate it. I don't think that lecturing everyone "No, you really want to have 0 risk, you fools" is a successful programming language advocacy strategy.
      - 10y ago

andrepd 10y ago

It's not modern, it's C++98.

stinos 10y ago

Do you have more of these examples?

anon1385 10y ago
http://www.cvedetails.com/vulnerability-list/vendor_id-452/product_id-3264/opmemc-1/Mozilla-Firefox.html http://www.cvedetails.com/vulnerability-list/vendor_id-452/p... http://www.cvedetails.com/vulnerability-list/vendor_id-452/product_id-3264/opec-1/Mozilla-Firefox.html http://www.cvedetails.com/vulnerability-list/vendor_id-452/p...

ambrop7 10y ago

If it has memory safety issues then it's not written by experts :)

dbaupp 10y ago
So there's no such thing as a C++ expert? That statement is dangerously close to a No True Scotsman: IME even people who seem to fit any reasonable definition of expert (committee members, compiler developers) still make memory-safety mistakes.
- civility 10y ago
  > That statement is dangerously close to a No True Scotsman It also had a smiley in it. I'm pretty sure you missed the joke and don't realize you're preaching to the choir.
  - dbaupp 10y ago
    This is Poe's law territory, e.g. a lot of your own comments sound very similar to the parent, and there are other emoticons more commonly used to indicate sarcasm/joke.
    - civility 10y ago
      > This is Poe's law territory Heh, I think that's possibly the only virtue to sarcasm: it confuses the pedants. I use friendly smileys or the word "heh" when I'm trying to be jovial, and I'm willing to give that poster the benefit of the doubt. :-) > a lot of your own comments sound very similar to the parent Which comments? > there are other emoticons more commonly used to indicate sarcasm/joke I think any common standard about something like this probably only applies to a narrow clique.

ska 10y ago

Ignoring the straw man, can you explain how c++98 code provides a counterexample for anything in modern c++?

mackal 10y ago

This isn't modern c++, but whatever.

randyrand 10y ago

No, but not everything needs to be memory safe. That's what the kernel is there for. You can typically just restart the program. The classic program safety vs programmer time tradeoff.

AaronFriel 10y ago
If your program isn't memory safe, it's very often the case that someone can make your program run their program, at which point the kernel doesn't know that your program didn't intend to modify itself. W^X/NX bits and other technologies don't totally obviate the issue, as ROP gadgets can be used to defeat it. And so on, there's a whole domain of computer science dedicated to that arms race and no evidence that it's stopping any time soon. On the other hand, a Rust program without unsafe should simply never execute code outside of its defined control flow, it's not possible to hijack any control flow on the stack or heap, and so a running program under arbitrary user input can only ever explore execution paths that exist in the absence of memory unsafety. No ROP gadgets or heap/stack smashing, no overflows leading to overwriting a function definition in memory, no overwriting the parameters of a function to cause impossible branches to be taken, and so on.
- cbhl 10y ago
  I recall that there was at least one shipping video game where "someone" was "my future self" -- they exploited a buffer overflow after-the-fact in a shipped video game (a EULA dialog?) in order to make it run an updater.
- randyrand 10y ago
  Not every program is intended to be connected to the internet or have user provided input. I agree, for many programs memory safety matters. But there are a large chunk of programs where it doesnt matter/is not worth the effort.
  - msbarnett 10y ago
    > Not every program is intended to be connected to the internet or have user provided input. While true, I think the vast majority of programs do do one of these two things (and increasingly, both), whereas the majority of programmers seem to think that what they work on "isn't a security issue". It's this disconnect that is giving us the Internet of Crap. Your phone apps, your fridge, your video games, your text editor -- every program I interact with every day -- it's all a security issue

jasode 10y ago

Maybe you're right that it's wrong to think that modern C++17 (unique_ptr, shared_ptr) written by experts is free of memory safety issues. But in this specific case, it looks like old code from 2002[1]. No modern techniques such as std:unique_ptr. Just 1970s C style raw pointer manipulation. I suppose the contemporaneous compiler used by John Maddock would have been C++98?!? [1] one example of a source file mentioned by the bug report: http://www.boost.org/doc/libs/1_63_0/boost/regex/v4/perl_matcher.hpp http://www.boost.org/doc/libs/1_63_0/boost/regex/v4/perl_mat...

dnljms 10y ago
The main windows compiler would have been Visual C++ 6, which was released before standardization, and had notable differences from C++98. It was also buggy for non-trivial templates. Visual C++ 2002 wasn't much better.

acconsta 10y ago

> modern C++ This library is old enough to drive...

gok 10y ago

I don't fundamentally disagree with you (any C++ bigger than a screenful of code probably has memory safety issues) but contrary to its reputation, I've find Boost to be of really poor code quality.

tonyedgecombe 10y ago
I've find Boost to be of really poor code quality Which is telling because it's raison d'etre is quality and it was written by some pretty smart people.

flukus 10y ago

> modern C++ written by experts is free of memory safety issues Which simply isn't good enough, it takes 10+ years to become expert level at anything, so what are people supposed to do to get to that level?