5 ms·

>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 whe

>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.
  - stouset 4y ago
    > Tell me what subset of the repo named "bc" you consider to be "the program" Clearly, the parts where you aren't able to find memory bugs.
    - ghoward 4y ago
      Anything built without the -a option to configure.sh. You can try the library too, but I did mess up that one time that you already know about.
  - ghoward 4y ago
    Okay, so I didn't say a release at first, but I meant to. That's only fair. Anything built without the -a option to configure.sh is "the program." That's the vast majority. You can try the library too, but there is that one mistake you already know about. I don't think there are any others though. And again, even with the things you all have found that are in random commits, it doesn't really matter; Rust isn't completely memory safe either. It's close, but not quite.
  - ghoward 4y ago
- stouset 4y ago
  "Find a memory bug in this repo. No, not those bugs. No, the ones in that part of the program are off limits. The ones I pushed but caught just before tagging don't count either because I noticed them just in time. Okay there was this one time where it happened when my complicated sanitizer setup broke without me realizing but that was a total fluke. And that other one also doesn't count because it definitely wouldn't have been stopped by Rust[1]." I'm almost tempted to believe this entire exchange was an elaborate setup to convince people to use memory-safe languages. [1] except I'm… pretty sure it would have been
  - gavinhoward 4y ago
    Seriously? Just try it. Break my `bc` in a release. I dare you. Until any of you do, you're just trolls or the RESF.
    - stouset 4y ago
      To what end? You’ve already stated elsewhere that your only point is that you can, under an increasingly strict set of conditions, write code that is (almost always) free of memory bugs. Great! Nobody is hiding around the corner waiting to take `gcc` or `clang` away from you if you want to keep using them. Nobody's threatening to take away your software engineering license if we catch you writing a memory bug. This whole thread is ridiculous. “The safety improvements in modern cars are substantial. If you're buying a new car these days, you should probably buy one made after 2018.” “Well I'm still driving my 1969 Malibu. Plus I’ve never been in an accident so I don’t need those safety features.” “Okay but… what are those dents in your car?” “I said no accidents on public roads. Prove me wrong or STFU.”
      - gavinhoward 4y ago
        The RESF seems to want to take C away from me. They seem to think I am a bad person for using C. They seem to think I am a bad programmer for using C. To refute all of that, I point people at some code that they would probably struggle to break.

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.
- stouset 4y ago
  > Tell me what subset of the repo named "bc" you consider to be "the program" Clearly, the parts where you aren't able to find memory bugs.
  - ghoward 4y ago
    Anything built without the -a option to configure.sh. You can try the library too, but I did mess up that one time that you already know about.
- ghoward 4y ago
  Okay, so I didn't say a release at first, but I meant to. That's only fair. Anything built without the -a option to configure.sh is "the program." That's the vast majority. You can try the library too, but there is that one mistake you already know about. I don't think there are any others though. And again, even with the things you all have found that are in random commits, it doesn't really matter; Rust isn't completely memory safe either. It's close, but not quite.
- ghoward 4y ago
stouset 4y ago
"Find a memory bug in this repo. No, not those bugs. No, the ones in that part of the program are off limits. The ones I pushed but caught just before tagging don't count either because I noticed them just in time. Okay there was this one time where it happened when my complicated sanitizer setup broke without me realizing but that was a total fluke. And that other one also doesn't count because it definitely wouldn't have been stopped by Rust[1]." I'm almost tempted to believe this entire exchange was an elaborate setup to convince people to use memory-safe languages. [1] except I'm… pretty sure it would have been
- gavinhoward 4y ago
  Seriously? Just try it. Break my `bc` in a release. I dare you. Until any of you do, you're just trolls or the RESF.
  - stouset 4y ago
    To what end? You’ve already stated elsewhere that your only point is that you can, under an increasingly strict set of conditions, write code that is (almost always) free of memory bugs. Great! Nobody is hiding around the corner waiting to take `gcc` or `clang` away from you if you want to keep using them. Nobody's threatening to take away your software engineering license if we catch you writing a memory bug. This whole thread is ridiculous. “The safety improvements in modern cars are substantial. If you're buying a new car these days, you should probably buy one made after 2018.” “Well I'm still driving my 1969 Malibu. Plus I’ve never been in an accident so I don’t need those safety features.” “Okay but… what are those dents in your car?” “I said no accidents on public roads. Prove me wrong or STFU.”
    - gavinhoward 4y ago
      The RESF seems to want to take C away from me. They seem to think I am a bad person for using C. They seem to think I am a bad programmer for using C. To refute all of that, I point people at some code that they would probably struggle to break.