6 ms·

> I do not care about safety (memory or otherwise) - my code doesn't take arbitrary input, run on shared hardware, do much of anything over networks or have mem

> I do not care about safety (memory or otherwise) - my code doesn't take arbitrary input, run on shared hardware, do much of anything over networks or have memory safety crashes How do you know it's the case that you don't have memory safety defects in your implementation? It's almost certainly not the case that you don't care about safety. Out of bounds accesses and writes would make the simulation defective. Defective simulations are useless. However it might make sense if you said that you don't find yourself fixing defects like these often.

integricho 7y ago
Luckily, we have sanitizers now.
vbarrielle 7y ago
The very popular C++ linear algebra library Eigen has bounds checking for matrices by default, but you can turn them off when defining NDEBUG. This means most out of bounds accesses are found during development.
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
bluGill 7y ago
Memory safety defects tend to manifest themselves in obvious ways. A few unit tests, and some work in memory sanitizes will find them.
- pcwalton 7y ago
  This is empirically not true. A look through https://twitter.com/lazyfishbarrel https://twitter.com/lazyfishbarrel confirms this.
  - bluGill 7y ago
    The exceptions tend to escape notice for years. They get a lot of attention (and are often really hard to fix unlike the early ones), but I stand by my statement: most are easily found and fixed - but they are also fixed early in development so you don't hear about them.
- RaleyField 7y ago
  If it's so obvious then why am I receiving security patches for my Linux desktop almost every day?
  - bluGill 7y ago
    Many reasons. There is a long tail of exceptions to my statement, hard to find things that escape notice for years. There are a lot of security issues that are not really memory safety as we are talking about here. (many are memory safety in a way that has nothing to do with getting your allocate/free wrong - using uninitialized memory for example). Some of them are subtle new attacks that were just discovered and now need to be mitigated.
zarkov99 7y ago
I work in a domain where memory defects do matter, but with moderately disciplined development, that is no naked news/deletes, no naked array access, no locks, etc, we hardly see any memory problems in a high concurrency, high throughput, mission critical environment. At least for my group, Rust's memory safety focus would not move the needle.
keldaris 7y ago
I fix out of bounds errors fairly frequently, but every single one of them is a trivial typo that is caught instantly and takes under 10 seconds to fix and re-test, literally. The reason for that is that in my domain all the memory requirements that matter [1] are known statically down to exact sizes, which are mathematically provable. Making good use of this fact makes most memory safety bugs either impossible (like the usual double frees, use after free, etc.) or trivial to address (like out of bounds accesses). The common approach, which frankly horrifies me, of dynamically allocating different objects all over the place at runtime and trying to care about it to the least possible extent is just utterly alien in this domain (which I think is the point of similarity to game engines). Consequently, things like the borrow checker, that are fundamentally designed to make this common approach safer and less bug prone elicit a "um... why?" sort of reaction from people like me, because they seem to be completely beside the point [2]. [1] Yes, there are scratch buffers for things like log output and other details of convenience. None of them impact the actual simulation and all are easily handled by a trivial bump allocator over a static buffer. Bugs are unlikely and rare, but if they do happen they don't really affect anything of consequence. [2] The borrow checker is just a random example, I also tend to avoid most of "modern" C++ for the same reasons and write in a fairly orthodox style.

integricho 7y ago

Luckily, we have sanitizers now.

vbarrielle 7y ago

The very popular C++ linear algebra library Eigen has bounds checking for matrices by default, but you can turn them off when defining NDEBUG. This means most out of bounds accesses are found during development.

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

bluGill 7y ago

Memory safety defects tend to manifest themselves in obvious ways. A few unit tests, and some work in memory sanitizes will find them.

pcwalton 7y ago
This is empirically not true. A look through https://twitter.com/lazyfishbarrel https://twitter.com/lazyfishbarrel confirms this.
- bluGill 7y ago
  The exceptions tend to escape notice for years. They get a lot of attention (and are often really hard to fix unlike the early ones), but I stand by my statement: most are easily found and fixed - but they are also fixed early in development so you don't hear about them.
RaleyField 7y ago
If it's so obvious then why am I receiving security patches for my Linux desktop almost every day?
- bluGill 7y ago
  Many reasons. There is a long tail of exceptions to my statement, hard to find things that escape notice for years. There are a lot of security issues that are not really memory safety as we are talking about here. (many are memory safety in a way that has nothing to do with getting your allocate/free wrong - using uninitialized memory for example). Some of them are subtle new attacks that were just discovered and now need to be mitigated.

zarkov99 7y ago

I work in a domain where memory defects do matter, but with moderately disciplined development, that is no naked news/deletes, no naked array access, no locks, etc, we hardly see any memory problems in a high concurrency, high throughput, mission critical environment. At least for my group, Rust's memory safety focus would not move the needle.

keldaris 7y ago

I fix out of bounds errors fairly frequently, but every single one of them is a trivial typo that is caught instantly and takes under 10 seconds to fix and re-test, literally. The reason for that is that in my domain all the memory requirements that matter [1] are known statically down to exact sizes, which are mathematically provable. Making good use of this fact makes most memory safety bugs either impossible (like the usual double frees, use after free, etc.) or trivial to address (like out of bounds accesses). The common approach, which frankly horrifies me, of dynamically allocating different objects all over the place at runtime and trying to care about it to the least possible extent is just utterly alien in this domain (which I think is the point of similarity to game engines). Consequently, things like the borrow checker, that are fundamentally designed to make this common approach safer and less bug prone elicit a "um... why?" sort of reaction from people like me, because they seem to be completely beside the point [2]. [1] Yes, there are scratch buffers for things like log output and other details of convenience. None of them impact the actual simulation and all are easily handled by a trivial bump allocator over a static buffer. Bugs are unlikely and rare, but if they do happen they don't really affect anything of consequence. [2] The borrow checker is just a random example, I also tend to avoid most of "modern" C++ for the same reasons and write in a fairly orthodox style.