6 ms·

Not to get too much into the weeds, but in my experience in HPC for numerical work out-of-bounds read/writes are almost never an issue. I say almost because I'm

by steev 7y ago

Not to get too much into the weeds, but in my experience in HPC for numerical work out-of-bounds read/writes are almost never an issue. I say almost because I'm sure someone somewhere as slipped up, but I've literally never had this problem. A priori you know your bounds and looping within them is trivial. I don't think I've ever encountered any data where you did not know the dimensions at program startup. I have experimented with Rust because I thoroughly enjoy the language (but am not an expert), and immediately got bit by bounds checks during vector indexing. I also find if you write modern, idiomatic C++ code you rarely, if ever, have to worry about memory safety issues.

pcwalton 7y ago
> I also find if you write modern, idiomatic C++ code you rarely, if ever, have to worry about memory safety issues. This is empirically not true. Tons of memory safety issues are found (and exploited) all the time in modern idiomatic C++ codebases.
- FpUser 7y ago
  This is very generic statement. I do write servers for example that run non stop and frankly I've long forgotten when the production version caused memory issues. Basically combination of being diligent, using memory leak detection tools and certain programming style works for me just fine. For example my latest game server is up more than 2 month already and the only reason it gets restarted is that I am updating it with the new version.
  - pcwalton 7y ago
    You get a very different view when you're looking at actively attacked codebases. Memory safety issues are everywhere. https://twitter.com/lazyfishbarrel https://twitter.com/lazyfishbarrel is very much worth reading.
    - FpUser 7y ago
      I can not be responsible for however said highly attacked systems were designed and hence can not judge. In my own cases I use proprietary protocols for client-server communications that more or less ensure that memory bounds are not broken. Of course attackers might be able to punch holes in lower layers ( UDP for example ) over which I have no direct control but in this case Rust would use the same UDP stack and offer no advantage.
      - mcqueenjordan 7y ago
        I’m glad to hear that your code is unbreakable and without any bugs, but pcwalton’s claim is still absolutely correct. > This is empirically not true. Tons of memory safety issues are found (and exploited) all the time in modern idiomatic C++ codebases.
        FpUser 7y ago
        "I’m glad to hear that your code is unbreakable and without any bugs, but pcwalton’s claim is still absolutely correct" I smell sarcasm here. I do not claim my code to be unbreakable. I do believe it is REASONABLY safe by design. pcwalton's claim is generic claim about generic code that may have no relevance to particular situations. Mine for example
    - jcelerier 7y ago
      let's be serious, chromium and firefox are more 90s style codebases than 2010s. There's thousands of raw malloc calls when I grep in the chromium source tree, and let's not even start talking about firefox where in the same file you've got : - raw mallocs : https://github.com/mozilla/gecko/blob/central/dom/plugins/ipc/FunctionBroker.cpp#L1252 https://github.com/mozilla/gecko/blob/central/dom/plugins/ip... - new / delete : https://github.com/mozilla/gecko/blob/central/dom/plugins/ipc/FunctionBroker.cpp#L1374 https://github.com/mozilla/gecko/blob/central/dom/plugins/ip... - "whatever.Allocate<T>" : https://github.com/mozilla/gecko/blob/central/dom/plugins/ipc/FunctionBroker.cpp#L1186 https://github.com/mozilla/gecko/blob/central/dom/plugins/ip... and that's not limited to a single file... look at this : https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb92c09ba67a2a5c218b/netwerk/sctp/datachannel/DataChannel.cpp https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb... - some malloc and new, again - you also get some unique_ptr (because "modern" m'see) : https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb92c09ba67a2a5c218b/netwerk/sctp/datachannel/DataChannel.cpp#L846 https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb... - moz_xmalloc because why not ? https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb92c09ba67a2a5c218b/netwerk/sctp/datachannel/DataChannel.cpp#L846 https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb... - oh and did you know about our own custom reference counting pointer ? https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb92c09ba67a2a5c218b/netwerk/sctp/datachannel/DataChannel.cpp#L2021 https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb... etc etc... when you've got 35 different ways to allocate objects used willy-nilly of course things go wrong. Most modern codebases only ever use automatic storage, and unique / shared_ptr.
  - jzoch 7y ago
    >being diligent, using memory leak detection tools and certain programming style Thats the whole point. You need to do these things in C++, not in rust. In rust you get it for free and dont need to be an expert and use runtime detection tools or even static analyzers besides your compiler (w.r.t to memory safety and some classes of data races. These things can be useful in other domains) People make the same assertions about dynamically typed languages at scale and how you "only" need to write tests that assert the types or "i wrote the function and know which type is passed duh" or "i write unit tests that would catch this" when a statically typed language tells you at compile time whether or not it will work. No intelligence required.
    - FpUser 7y ago
      You have a valid point. However practically speaking smart pointers in C++ eliminate most of headaches. At least for me personally so I do not really consider it a big nuisance. But yes I agree that for many people choosing Rust could be preferred way.
  - MaulingMonkey 7y ago
    > memory leak detection tools Hopefully you're not only relying on those - valgrind, address sanitizer, fuzzing tools, static analysis, etc. are a must for network-facing C++ (or unsafe Rust) as far as I'm concerned. You're not just looking for leaks, but use after free bugs, single byte overflows, bad casts triggered by bad data, and a whole slew of other potential problems.
- jandrewrogers 7y ago
  I can't speak for all modern C++ code bases but this assertion is manifestly false in every modern C++ code base I have come in contact with for a long time now. There have been some gross exploits in publicly audited "safe" Rust code in recent months -- does this mean no one should use Rust? Are you going to make a hobby of denouncing Rust in public forums as a consequence? I don't understand the desperate need to paint all modern C++ code bases as dangerously unsafe. It is demonstrably not true and doesn't reflect well on the motivations of those that would blindly assert it. Modern C++ has many issues and, like all programming languages, is the scene of many bugs. Just not memory safety issues. Furiously asserting that memory safety is an issue does not manufacture fact.
  - pcwalton 7y ago
    > I don't understand the desperate need to paint all modern C++ code bases as dangerously unsafe. Because the idea that security vulnerabilities can be fixed by just "modernizing" C++ codebases is actively harming security, by discouraging investment in memory-safe languages. > It is demonstrably not true and doesn't reflect well on the motivations of those that would blindly assert it. It is demonstrably true, as http://twitter.com/lazyfishbarrel http://twitter.com/lazyfishbarrel shows. Perhaps consider that those of us who work on browsers, which are some of the largest most-attacked pieces of software in the world, would know what we are talking about.

by steev 7y ago

pcwalton 7y ago

> I also find if you write modern, idiomatic C++ code you rarely, if ever, have to worry about memory safety issues. This is empirically not true. Tons of memory safety issues are found (and exploited) all the time in modern idiomatic C++ codebases.

FpUser 7y ago
This is very generic statement. I do write servers for example that run non stop and frankly I've long forgotten when the production version caused memory issues. Basically combination of being diligent, using memory leak detection tools and certain programming style works for me just fine. For example my latest game server is up more than 2 month already and the only reason it gets restarted is that I am updating it with the new version.
- pcwalton 7y ago
  You get a very different view when you're looking at actively attacked codebases. Memory safety issues are everywhere. https://twitter.com/lazyfishbarrel https://twitter.com/lazyfishbarrel is very much worth reading.
  - FpUser 7y ago
    I can not be responsible for however said highly attacked systems were designed and hence can not judge. In my own cases I use proprietary protocols for client-server communications that more or less ensure that memory bounds are not broken. Of course attackers might be able to punch holes in lower layers ( UDP for example ) over which I have no direct control but in this case Rust would use the same UDP stack and offer no advantage.
    - mcqueenjordan 7y ago
      I’m glad to hear that your code is unbreakable and without any bugs, but pcwalton’s claim is still absolutely correct. > This is empirically not true. Tons of memory safety issues are found (and exploited) all the time in modern idiomatic C++ codebases.
      - FpUser 7y ago
        "I’m glad to hear that your code is unbreakable and without any bugs, but pcwalton’s claim is still absolutely correct" I smell sarcasm here. I do not claim my code to be unbreakable. I do believe it is REASONABLY safe by design. pcwalton's claim is generic claim about generic code that may have no relevance to particular situations. Mine for example
  - jcelerier 7y ago
    let's be serious, chromium and firefox are more 90s style codebases than 2010s. There's thousands of raw malloc calls when I grep in the chromium source tree, and let's not even start talking about firefox where in the same file you've got : - raw mallocs : https://github.com/mozilla/gecko/blob/central/dom/plugins/ipc/FunctionBroker.cpp#L1252 https://github.com/mozilla/gecko/blob/central/dom/plugins/ip... - new / delete : https://github.com/mozilla/gecko/blob/central/dom/plugins/ipc/FunctionBroker.cpp#L1374 https://github.com/mozilla/gecko/blob/central/dom/plugins/ip... - "whatever.Allocate<T>" : https://github.com/mozilla/gecko/blob/central/dom/plugins/ipc/FunctionBroker.cpp#L1186 https://github.com/mozilla/gecko/blob/central/dom/plugins/ip... and that's not limited to a single file... look at this : https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb92c09ba67a2a5c218b/netwerk/sctp/datachannel/DataChannel.cpp https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb... - some malloc and new, again - you also get some unique_ptr (because "modern" m'see) : https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb92c09ba67a2a5c218b/netwerk/sctp/datachannel/DataChannel.cpp#L846 https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb... - moz_xmalloc because why not ? https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb92c09ba67a2a5c218b/netwerk/sctp/datachannel/DataChannel.cpp#L846 https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb... - oh and did you know about our own custom reference counting pointer ? https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb92c09ba67a2a5c218b/netwerk/sctp/datachannel/DataChannel.cpp#L2021 https://github.com/mozilla/gecko/blob/3e6d6e013400af38f85ceb... etc etc... when you've got 35 different ways to allocate objects used willy-nilly of course things go wrong. Most modern codebases only ever use automatic storage, and unique / shared_ptr.
- jzoch 7y ago
  >being diligent, using memory leak detection tools and certain programming style Thats the whole point. You need to do these things in C++, not in rust. In rust you get it for free and dont need to be an expert and use runtime detection tools or even static analyzers besides your compiler (w.r.t to memory safety and some classes of data races. These things can be useful in other domains) People make the same assertions about dynamically typed languages at scale and how you "only" need to write tests that assert the types or "i wrote the function and know which type is passed duh" or "i write unit tests that would catch this" when a statically typed language tells you at compile time whether or not it will work. No intelligence required.
  - FpUser 7y ago
    You have a valid point. However practically speaking smart pointers in C++ eliminate most of headaches. At least for me personally so I do not really consider it a big nuisance. But yes I agree that for many people choosing Rust could be preferred way.
- MaulingMonkey 7y ago
  > memory leak detection tools Hopefully you're not only relying on those - valgrind, address sanitizer, fuzzing tools, static analysis, etc. are a must for network-facing C++ (or unsafe Rust) as far as I'm concerned. You're not just looking for leaks, but use after free bugs, single byte overflows, bad casts triggered by bad data, and a whole slew of other potential problems.
jandrewrogers 7y ago
I can't speak for all modern C++ code bases but this assertion is manifestly false in every modern C++ code base I have come in contact with for a long time now. There have been some gross exploits in publicly audited "safe" Rust code in recent months -- does this mean no one should use Rust? Are you going to make a hobby of denouncing Rust in public forums as a consequence? I don't understand the desperate need to paint all modern C++ code bases as dangerously unsafe. It is demonstrably not true and doesn't reflect well on the motivations of those that would blindly assert it. Modern C++ has many issues and, like all programming languages, is the scene of many bugs. Just not memory safety issues. Furiously asserting that memory safety is an issue does not manufacture fact.
- pcwalton 7y ago
  > I don't understand the desperate need to paint all modern C++ code bases as dangerously unsafe. Because the idea that security vulnerabilities can be fixed by just "modernizing" C++ codebases is actively harming security, by discouraging investment in memory-safe languages. > It is demonstrably not true and doesn't reflect well on the motivations of those that would blindly assert it. It is demonstrably true, as http://twitter.com/lazyfishbarrel http://twitter.com/lazyfishbarrel shows. Perhaps consider that those of us who work on browsers, which are some of the largest most-attacked pieces of software in the world, would know what we are talking about.