5 ms·

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 re

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
  I realize I should answer the signal part. tokio::signal-type code would not work for `bc` signals. `bc` is a special program; most programs are I/O-bound, but `bc` is both I/O- and CPU-bound. And it's interactive, so it's got to respond to the user as fast as possible. It's quite possible for a user to enter an expression, not realizing how expensive it is to compute (since `bc`'s numbers can be arbitrarily large). In that case, a `SIGINT` should be responded to instantly. Turning signals into an event stream to read would not do that because the signal handler literally has to `longjmp()` out of itself. It won't `longjmp()` out if it's not safe to do so, but it can be safe to do so. And when it is not safe to do so, it will set a flag and return normally. Then the code that wasn't safe to jump around finishes, it will check the flag and jump itself once it is safe. This is what keeps my `bc` responsive even if you have a long-running computation. To see this, compile and run my `bc`, and give it this input: >>> 2^2^32 It will hang because it's calculating a LARGE number. Press Ctrl+C. It will instantly return to the input prompt. I might be wrong that tokio::signal cannot do that, and if so, I apologize. But it doesn't appear so from your description. Also, I have the same sort of code in my new project to turn signals into an event stream in C.
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.

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
I realize I should answer the signal part. tokio::signal-type code would not work for `bc` signals. `bc` is a special program; most programs are I/O-bound, but `bc` is both I/O- and CPU-bound. And it's interactive, so it's got to respond to the user as fast as possible. It's quite possible for a user to enter an expression, not realizing how expensive it is to compute (since `bc`'s numbers can be arbitrarily large). In that case, a `SIGINT` should be responded to instantly. Turning signals into an event stream to read would not do that because the signal handler literally has to `longjmp()` out of itself. It won't `longjmp()` out if it's not safe to do so, but it can be safe to do so. And when it is not safe to do so, it will set a flag and return normally. Then the code that wasn't safe to jump around finishes, it will check the flag and jump itself once it is safe. This is what keeps my `bc` responsive even if you have a long-running computation. To see this, compile and run my `bc`, and give it this input: >>> 2^2^32 It will hang because it's calculating a LARGE number. Press Ctrl+C. It will instantly return to the input prompt. I might be wrong that tokio::signal cannot do that, and if so, I apologize. But it doesn't appear so from your description. Also, I have the same sort of code in my new project to turn signals into an event stream in C.

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.