7 ms·

> In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; No. This is only true if you don't care about occasi

> In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; No. This is only true if you don't care about occasional bugs. e.g. hobby projects. But if you're talking about mission-critical or security-critical software, there is a gap - or a canyon - between C vs C++ vs Rust. And no amount of extra "efforts" by the programmer's part can bridge those gaps completely.

ghoward 4y ago
The true test of what I said is "show me the code." The code is my `bc`. [1] Find a memory bug, any memory bug, in my `bc` after 1.0. Rust has occasional memory bugs too; I mentioned that specifically. It still happens. So if you really are correct, break my `bc`. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc
- stouset 4y ago
  Yes, let’s ignore the quite literally millions of examples of prior art for memory bugs in C/C++ programs because you believe you’ve managed to build a single-threaded CLI calculator that doesn’t have any. I know how to call `strcpy` safely. Are we clear to put that back into the Linux kernel then?
  - ghoward 4y ago
    Notice that in my first post, I said to use Rust where practical. I never said that everyone should use C. I'm only claiming that I personally can do just as well in C as I could do in Rust, and that I prefer to work in C, so I might as well. Break my `bc`.
    - stouset 4y ago
      I honestly don't understand the point of your post then. Are you looking for a pat on the back?
      - classified 4y ago
- Arnavion 4y ago
  >Find a memory bug, any memory bug, in my `bc` after 1.0. I'm surprised by this confidence given one of the commits on the first page is "Fix a double-free when using expressions and sending SIGINT". And going through the commit history quickly reveals "Fix memory bugs in bcl" (a value not being initialized) and "Fix memory leaks in bcl" (missing dealloc), all within the last two months and all which are trivially not a problem in Rust.
  - ncmncm 4y ago
    Rust is perfectly happy to leak. But as in C++, there is no temptation to.
  - gavinhoward 4y ago
    Notice that I said to find a memory bug in a release, not just any commit. Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development. The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be zeroed) to allocated. But I also said to find one in the program, not the library. I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0. Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.
    - JSoet 4y ago
      I am also wondering about your confidence given the fact that there are obviously memory bugs during development... what gives you so much confidence that no memory bugs exist in released versions? Do you have an extensive test suite with valgrind /etc to ensure that there aren't any memory bugs before a release but some can slip in in intermediate versions? Or what do you do that gives you the confidence to say that there aren't any memory bugs in the released versions? Or what is involved in all the extra effort it takes to make a memory bug free c program?
    - Arnavion 4y ago
      >Notice that I said to find a memory bug in a release, not just any commit. You did not say anything of the sort. >But I also said to find one in the program, not the library. You did not say anything of the sort. You said: >>The code is my `bc`. [1] >>Find a memory bug, any memory bug, in my `bc` after 1.0. >>[1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc But okay, let's acknowledge the moved goalposts. >I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0. Tell me what subset of the repo named "bc" you consider to be "the program" >Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model. Crates like tokio::signal allow a signal to be converted to a stream of events, which can be handled along with any other events in the program, instead of interrupting the current fn in the middle and necessitating longjmp shenanigans. Since the existing stack is not interrupted in any special way, dtors fire as they're supposed to.
- drivebycomment 4y ago
  You misunderstood what I mean by "gap" here. The gap isn't that it is impossible to produce security/reliability equivalent program using C vs Rust, which you seem to be arguing. The gap is that statistically for many code written in real world for various degree of efforts, Rust code will have much less of security/reliability issues, and it will take much less effort to get to the similar quality point compared to C or C++, and that gap is NOT bridgeable by making C programmer better or by inventing better conventions and styles.
blub 4y ago
Mission critical is almost meaningless when applied to the entire software industry. It’s whatever each company wrote their core software in. For twitter Ruby was mission critical, for Facebook it was PHP. Security critical is also rather meaningless, because the idea that a specific language must be used to write secure software is something that the Rust community is claiming but is otherwise unproven and not particularly popular as an opinion. In fact I’ve seen many counters that nearly any GC language offers the same security guarantees as Rust. Finally, there’s the mighty inconvenient fact that a large amount of safety-critical software (a well-defined term and domain!) is written in C and C++ with a track record of multiple decades while Rust is completely unproven.
- the_arcadian 4y ago
  > Finally, there’s the mighty inconvenient fact that a large amount of safety-critical software (a well-defined term and domain!) is written in C and C++ with a track record of multiple decades Well stated.

ghoward 4y ago

The true test of what I said is "show me the code." The code is my `bc`. [1] Find a memory bug, any memory bug, in my `bc` after 1.0. Rust has occasional memory bugs too; I mentioned that specifically. It still happens. So if you really are correct, break my `bc`. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc

stouset 4y ago
Yes, let’s ignore the quite literally millions of examples of prior art for memory bugs in C/C++ programs because you believe you’ve managed to build a single-threaded CLI calculator that doesn’t have any. I know how to call `strcpy` safely. Are we clear to put that back into the Linux kernel then?
- ghoward 4y ago
  Notice that in my first post, I said to use Rust where practical. I never said that everyone should use C. I'm only claiming that I personally can do just as well in C as I could do in Rust, and that I prefer to work in C, so I might as well. Break my `bc`.
  - stouset 4y ago
    I honestly don't understand the point of your post then. Are you looking for a pat on the back?
    - classified 4y ago
Arnavion 4y ago
>Find a memory bug, any memory bug, in my `bc` after 1.0. I'm surprised by this confidence given one of the commits on the first page is "Fix a double-free when using expressions and sending SIGINT". And going through the commit history quickly reveals "Fix memory bugs in bcl" (a value not being initialized) and "Fix memory leaks in bcl" (missing dealloc), all within the last two months and all which are trivially not a problem in Rust.
- ncmncm 4y ago
  Rust is perfectly happy to leak. But as in C++, there is no temptation to.
- gavinhoward 4y ago
  Notice that I said to find a memory bug in a release, not just any commit. Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development. The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be zeroed) to allocated. But I also said to find one in the program, not the library. I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0. Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.
  - JSoet 4y ago
    I am also wondering about your confidence given the fact that there are obviously memory bugs during development... what gives you so much confidence that no memory bugs exist in released versions? Do you have an extensive test suite with valgrind /etc to ensure that there aren't any memory bugs before a release but some can slip in in intermediate versions? Or what do you do that gives you the confidence to say that there aren't any memory bugs in the released versions? Or what is involved in all the extra effort it takes to make a memory bug free c program?
  - Arnavion 4y ago
    >Notice that I said to find a memory bug in a release, not just any commit. You did not say anything of the sort. >But I also said to find one in the program, not the library. You did not say anything of the sort. You said: >>The code is my `bc`. [1] >>Find a memory bug, any memory bug, in my `bc` after 1.0. >>[1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc But okay, let's acknowledge the moved goalposts. >I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0. Tell me what subset of the repo named "bc" you consider to be "the program" >Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model. Crates like tokio::signal allow a signal to be converted to a stream of events, which can be handled along with any other events in the program, instead of interrupting the current fn in the middle and necessitating longjmp shenanigans. Since the existing stack is not interrupted in any special way, dtors fire as they're supposed to.
drivebycomment 4y ago
You misunderstood what I mean by "gap" here. The gap isn't that it is impossible to produce security/reliability equivalent program using C vs Rust, which you seem to be arguing. The gap is that statistically for many code written in real world for various degree of efforts, Rust code will have much less of security/reliability issues, and it will take much less effort to get to the similar quality point compared to C or C++, and that gap is NOT bridgeable by making C programmer better or by inventing better conventions and styles.

blub 4y ago

Mission critical is almost meaningless when applied to the entire software industry. It’s whatever each company wrote their core software in. For twitter Ruby was mission critical, for Facebook it was PHP. Security critical is also rather meaningless, because the idea that a specific language must be used to write secure software is something that the Rust community is claiming but is otherwise unproven and not particularly popular as an opinion. In fact I’ve seen many counters that nearly any GC language offers the same security guarantees as Rust. Finally, there’s the mighty inconvenient fact that a large amount of safety-critical software (a well-defined term and domain!) is written in C and C++ with a track record of multiple decades while Rust is completely unproven.

the_arcadian 4y ago
> Finally, there’s the mighty inconvenient fact that a large amount of safety-critical software (a well-defined term and domain!) is written in C and C++ with a track record of multiple decades Well stated.